CLI v. GUI

[eekee]

I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea?

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.

OTOH, you could also use it as a general peripheral and then implement the OS with whatever hardware you like as long as it has 8x PCI express. That has the advantage of learning both how to create complex hardware devices and OSes.

Very funny!

I was thinking of FPGA-based computers where the usual practice is to load one or more cores into the FPGA. See opencores.org for some examples. There are also FPGAS with CPU cores in the same package. 9front runs on one of these; a dual-core ARM with the FPGA handling Ethernet, SATA, USB, and DisplayPort. (DP wasn't fun, but required fewer pins than HDMI. HDMI would have taken the IO which was wanted for SATA.) The guy who developed the board loves C and hates Verilog. He made a simpler, C-like language for FPGAs. It compiles to Verilog. I don't think he had time to finish it though. I think he likes VHDL better than Verilog, but which one you get to use depends on your FPGA manufacturer. There are no open-source compilers here.

[bloodline]

I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea?

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.

Pah! FPGAs are cheating... No point building your own hardware if you aren't building it out of 7400 series chips.

[eekee]

Most applications also made use of "ARexx Ports", a scripting callback interface that allowed applications to "talk" with each other, or be "remote controlled" by scripts.

You know, Apple had a go at adding something like this in the 00s. I guess it didn't catch on, possibly because the scripting interface was some drag-and-drop flowchart thing. I was actually confused to the point I never got to try it, but then I was busy with a lot of other things at the time. I don't want to try it now; I don't fancy installing OS X 10.4 or 10.3 on the CF card my Mac uses for a disk now. 10.4 gets pretty swap-heavy on that little thing, and 10.3 crashed more than it ran!

[rdos]

I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea?

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.

OTOH, you could also use it as a general peripheral and then implement the OS with whatever hardware you like as long as it has 8x PCI express. That has the advantage of learning both how to create complex hardware devices and OSes.

Very funny!

I was thinking of FPGA-based computers where the usual practice is to load one or more cores into the FPGA. See opencores.org for some examples. There are also FPGAS with CPU cores in the same package. 9front runs on one of these; a dual-core ARM with the FPGA handling Ethernet, SATA, USB, and DisplayPort. (DP wasn't fun, but required fewer pins than HDMI. HDMI would have taken the IO which was wanted for SATA.) The guy who developed the board loves C and hates Verilog. He made a simpler, C-like language for FPGAs. It compiles to Verilog. I don't think he had time to finish it though. I think he likes VHDL better than Verilog, but which one you get to use depends on your FPGA manufacturer. There are no open-source compilers here.

I have this device: https://www.xilinx.com/products/boards- ... 705-g.html

Buying an evaluation board gives a lot of hardware, and also a limited license to their development tools which otherwise are pretty expensive.

They have a C environment they call "Microblaze", but I didn't like that too much so I wrote everything in Verilog instead.

I also bought a 1G sample, 2 channel ADC & DAC from Analog devices which interfaces through the FMC connection on the FPGA board. It was a lot of work to learn Verilog, and to create an environment that could configure the ADC through a PIC device interface and then send sample data through PCI express to RAM in the target computer. I also developed a driver for my OS that created a schedule for the ADC. It all works pretty well and I can sample up to 750 MHz and then transfer the data in real-time to the host. It was a fun project where I learned a lot about how PCI is implemented in devices.

There was also a lot of problems since the reference designs used MicroBlaze and the local SDRAM of the FPGA. MicroBlaze cannot keep up with an ADC running at 750 MHz.

It would be fun to explore the Ethernet device as well, but I've not had time for it and my license to the development tools soon expires.

Besides, this device also has a huge number of DSP slices and so it's possible to do very complex signal analysis in real-time, although I think it is much easier to do this on PC hardware, and so I decided it was better to get a fast PC with lots of RAM.

Another drawback of doing things with Verilog is that it takes a VERY long time to build the code when the project is complex. Debugging also was a bit different, with adding signal tracers to the design.

[rdos]

I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea?

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.

Pah! FPGAs are cheating... No point building your own hardware if you aren't building it out of 7400 series chips.

True. I've built stuff with those. However, then I went on with Microchip microcontrollers, and now I prefer FPGAs for anything more complex.

I've built a few hole-mounted PCBs and then got them professionally manufactured with the help of Macaos, but soldering something containing a complex FPGA is not for me. I also avoid surface-mounted stuff. That's why evaluation boards are a good alternative. You get av ready-made PCB with all the components soldered and everything is tested with reference designs.

Still, it is fun to build everything yourself.

[eekee]

I have this device: https://www.xilinx.com/products/boards- ... 705-g.html

Buying an evaluation board gives a lot of hardware, and also a limited license to their development tools which otherwise are pretty expensive.

They have a C environment they call "Microblaze", but I didn't like that too much so I wrote everything in Verilog instead.

I also bought a 1G sample, 2 channel ADC & DAC from Analog devices which interfaces through the FMC connection on the FPGA board. It was a lot of work to learn Verilog, and to create an environment that could configure the ADC through a PIC device interface and then send sample data through PCI express to RAM in the target computer. I also developed a driver for my OS that created a schedule for the ADC. It all works pretty well and I can sample up to 750 MHz and then transfer the data in real-time to the host. It was a fun project where I learned a lot about how PCI is implemented in devices.

There was also a lot of problems since the reference designs used MicroBlaze and the local SDRAM of the FPGA. MicroBlaze cannot keep up with an ADC running at 750 MHz.

It would be fun to explore the Ethernet device as well, but I've not had time for it and my license to the development tools soon expires.

Besides, this device also has a huge number of DSP slices and so it's possible to do very complex signal analysis in real-time, although I think it is much easier to do this on PC hardware, and so I decided it was better to get a fast PC with lots of RAM.

Another drawback of doing things with Verilog is that it takes a VERY long time to build the code when the project is complex. Debugging also was a bit different, with adding signal tracers to the design.

I thought it would be something like that. I like eval boards too. Did the display on it help with debugging at all?

CPUs implemented on FPGAs have a reputation of being a bit slow, which would explain your troubles with Microblaze. They're fast enough for Amiga-era hardware, but I guess if you wanted to do your signal processing on the card, you'd have to use the DSP.

Stray fact: Bloomberg do their financial computations with 100-digit integer BCD arithmetic units implemented in FPGA PCI cards. New York Stock Exchange uses floating point instead, and they just accept they'll lose shares occasionally.

@bloodline: my same friend who made the board with the ARM/FPGA made a 6502 out of 74HC. He had trouble getting it to 1MHz.

But I think we're waaaay off topic now!

[rdos]

I thought it would be something like that. I like eval boards too. Did the display on it help with debugging at all?

No. You cannot even see it when the card is fitted in a typical computer. The eight LEDs are enough and easier to use. For serious debugging, logic analyser components are added to the design. Alternatively, the PCI bar and memory contents could be viewed from the OS side.

But I think we're waaaay off topic now!

I suppose, but it is an interesting topic so I might start a new topic.

[Octocontrabass]

Graphics will likely be another microcontroller dynamically generating the video signal.

Are there any microcontrollers fast enough for that? Ordinary 640x480 VGA requires a 25MHz pixel clock!

The other day, I tried to work out if I could get 1080x1920 with only 16KB video memory.

If you can squeeze 128 pixels in each byte, you're good to go. Perhaps something with tiles like VGA text mode instead of individually-addressable pixels?

[bloodline]

Graphics will likely be another microcontroller dynamically generating the video signal.

Are there any microcontrollers fast enough for that? Ordinary 640x480 VGA requires a 25MHz pixel clock!

I have bit banged a black and white VGA signal using a Teensy 4.0 (600Mhz ARM uC). This only requires three signals (H Sync, V Sync and Video), I couldn’t get the GPIO switching fast enough to change 24 pins per pixel. I did try and even built three resistor ladder DACs on breadboards to tests it

On the Teensy forums, some members have had more success using the uC’s DMA...

[eekee]

New thread for graphics

[AndrewAPrice]

A GUI takes more effort because even after you're in the video mode itself, you need to deal with drawing fonts, navigation, layouts, etc. While a raw text mode CLI is the easiest thing because you just printf whatever and display it sequentially. For this reason, most OS's here start with a text mode CLI and most OSDev tutorials start by printing Hello World to 0xb8000.

Then you have text-based user interfaces, but I would consider these a GUI because they're still based around visual elements (buttons, windows, etc.) rather than a command-line. The fact that a TUI uses the graphics device's text-mode is an implementation detail. Likewise with graphical CLIs (terminal emulators, Mathematica, etc.) that are command-line but are implemented with a video mode.

My long term goal is a GUI and I'm thinking of having an immediate-mode style API, but until I get the basics of my microkernel down with regards to messaging and drivers, I'm keeping with a CLI because it's easy to debug.

[eekee]

A GUI takes more effort because even after you're in the video mode itself, you need to deal with drawing fonts, navigation, layouts, etc. While a raw text mode CLI is the easiest thing because you just printf whatever and display it sequentially. For this reason, most OS's here start with a text mode CLI and most OSDev tutorials start by printing Hello World to 0xb8000.

Yeah. Designing a good GUI toolkit takes a lot of planning, and even bad ones have lots of features which need implementing. On the other hand, here's an opinion I don't let out very often: I think hardware text modes were obsolete by 1990. I should probably try to come up with a tutorial on the simplest possible text rendering to graphical framebuffers if there isn't one already.

The fact that a TUI uses the graphics device's text-mode is an implementation detail.

My thoughts exactly!

Likewise with graphical CLIs (terminal emulators, Mathematica, etc.) that are command-line but are implemented with a video mode.

Not my thought in the slightest! All that matters to me is the way you use it. If you type commands, it's a CLI. If you point or navigate to active areas, it's a GUI. I've used one program which is a true hybrid between these two definitions: the Acme text editor from Plan 9. It's powerful.

until I get the basics of my microkernel down with regards to messaging and drivers, I'm keeping with a CLI because it's easy to debug.

That is true, especially if you have a CLI on a serial port for several reasons.