3 ms·

Out of curiosity, what is difficult about setting it up with Xilinx tools?

ChuckMcM 13y ago
Mostly the lack of any ability to disassociate stuff. You need to start in PlanAhead and design all the hardware then build the software stack for that hardware, and then you can maybe test some of your ideas you were trying to implement. My goal is to put together a system for teaching people about computers. Looking back one can teach the equivalent of a 4 year CS degree (the CS classes anyway) from 20 years ago to get them the fundamentals, to pretty much anyone, except that the platforms available to do that are very complex. I was trying to teach basic concepts to kids and either the systems were too complex (PC's) to really understand them all, or too simple (AVR) to do all of what you wanted. There were a lot of MCUs but most were designed (like the Atmel ATMega 328) for "embedding" so they had not enough RAM and too much flash for the kinds of things I got to do on a PDP-10 or a PDP-11 back in school. So I wrote a PDP-11 emulator for the ATMega 32. Its not all that hard and even running it out of serial FRAMs and with SPI emulating the front panel and switches, it can be as fast as an 11/23 was. But the reason I started there was that there was already other software that had been written for it (I was targeting an RT-11 bootup, but the smallest SD Card you can get is bigger than the largest Hard Drive you could use with RT-11 (140MB). A number of people argued (successfully) that while a PDP-11 could teach basic concepts well, it would be better if you could re-use the experience in a more 'modern' setting, so I've been using ARM Cortex-M processors in my latest iteration. The ARM-9 crosses a bit to far over the threshold but provides a great 'follow-on' after the basic concepts are covered. One huge problem though is video. My first video card was a Dazzler card (really easy S-100 video card) and later CGA, and VGA graphics. And while you can kinda/sorta to register level code on the RaspPi it was nothing like the C64 or Amstrad of its time. Those were machines you could understand completely. So a side project grew to build a '2D Framebuffer' for an inexpensive ARM system. I had been working the STM32F409 but just picked up an STM32F429 which has a simple frame buffer built in. Prior to that I was thinking something along the lines of the sun CG3 frame buffer with shared DRAM connected via the FSMC port on the ARM chip to provide 16MB of memory accessible to the FrameBuffer and user programs. The Zedboard provides a nice HDMI plug connected to FPGA fabric for doing that research even if the ARM9 is over kill, once finalized my plan was to move the Framebuffer design to a Spartan3e series (the one I was looking at is $10 in 1K quantities.) But what I have not been able to do is to build a system with the Zedboard and just iterate on the Framebuffer part. In the ideal scenario I'd be able to reconfigure the FPGA on a running system but that has its own issues. I'd settle for rebooting into the next generation framebuffer but all I've been able to do is full up place and route followed by full scale sysgen. Very very painful. More than you wanted to know I'm sure but it's a sore point with me :-)
- robomartin 13y ago
  > Mostly the lack of any ability to disassociate stuff. I think I get where you are coming from. I've never approached FPGA work in this manner. What I mean by that is that every single FPGA board I've worked on I designed from scratch for the specific narrow application we were trying to address. I haven't had the need for full or partial dynamic reconfiguration at all. Maybe I misunderstood. Modern tool sets from Xilinx (and probably Altera, but I am not that familiar with their offerings) have the ability to do incremental compilation. That, combined with allocating an area to your framebuffer code should net you reasonably quick design iterations. Unless you are trying to do more than the basics a frame buffer isn't all that complex. A standard DRAM controller core to talk to memory, a set of FIFO's and a state machine to decide who does what when. If this is strictly for painting text and some basic graphics on the screen it's a relatively simple matter to double or triple buffer the interface you can render text/graphics in the background and flip between the live and background buffers during the vertical blanking period. S-100. Ah. The good old days when you could actually wire-wrap your own peripheral boards. Here's a data point to date me: I ran AutoCAD on an S-100 system with a separate S-100 math co-processor card and a 640K ram-drive card. Worked like a charm. Oh, yes, interaction was through a VT-100 terminal (the real deal) and a tablet with a wired puck. How many people on HN do you figure actually touched an IMSAI (outside a museum)?

Mostly the lack of any ability to disassociate stuff. You need to start in PlanAhead and design all the hardware then build the software stack for that hardware, and then you can maybe test some of your ideas you were trying to implement. My goal is to put together a system for teaching people about computers. Looking back one can teach the equivalent of a 4 year CS degree (the CS classes anyway) from 20 years ago to get them the fundamentals, to pretty much anyone, except that the platforms available to do that are very complex. I was trying to teach basic concepts to kids and either the systems were too complex (PC's) to really understand them all, or too simple (AVR) to do all of what you wanted. There were a lot of MCUs but most were designed (like the Atmel ATMega 328) for "embedding" so they had not enough RAM and too much flash for the kinds of things I got to do on a PDP-10 or a PDP-11 back in school. So I wrote a PDP-11 emulator for the ATMega 32. Its not all that hard and even running it out of serial FRAMs and with SPI emulating the front panel and switches, it can be as fast as an 11/23 was. But the reason I started there was that there was already other software that had been written for it (I was targeting an RT-11 bootup, but the smallest SD Card you can get is bigger than the largest Hard Drive you could use with RT-11 (140MB). A number of people argued (successfully) that while a PDP-11 could teach basic concepts well, it would be better if you could re-use the experience in a more 'modern' setting, so I've been using ARM Cortex-M processors in my latest iteration. The ARM-9 crosses a bit to far over the threshold but provides a great 'follow-on' after the basic concepts are covered. One huge problem though is video. My first video card was a Dazzler card (really easy S-100 video card) and later CGA, and VGA graphics. And while you can kinda/sorta to register level code on the RaspPi it was nothing like the C64 or Amstrad of its time. Those were machines you could understand completely. So a side project grew to build a '2D Framebuffer' for an inexpensive ARM system. I had been working the STM32F409 but just picked up an STM32F429 which has a simple frame buffer built in. Prior to that I was thinking something along the lines of the sun CG3 frame buffer with shared DRAM connected via the FSMC port on the ARM chip to provide 16MB of memory accessible to the FrameBuffer and user programs. The Zedboard provides a nice HDMI plug connected to FPGA fabric for doing that research even if the ARM9 is over kill, once finalized my plan was to move the Framebuffer design to a Spartan3e series (the one I was looking at is $10 in 1K quantities.) But what I have not been able to do is to build a system with the Zedboard and just iterate on the Framebuffer part. In the ideal scenario I'd be able to reconfigure the FPGA on a running system but that has its own issues. I'd settle for rebooting into the next generation framebuffer but all I've been able to do is full up place and route followed by full scale sysgen. Very very painful. More than you wanted to know I'm sure but it's a sore point with me :-)

robomartin 13y ago
> Mostly the lack of any ability to disassociate stuff. I think I get where you are coming from. I've never approached FPGA work in this manner. What I mean by that is that every single FPGA board I've worked on I designed from scratch for the specific narrow application we were trying to address. I haven't had the need for full or partial dynamic reconfiguration at all. Maybe I misunderstood. Modern tool sets from Xilinx (and probably Altera, but I am not that familiar with their offerings) have the ability to do incremental compilation. That, combined with allocating an area to your framebuffer code should net you reasonably quick design iterations. Unless you are trying to do more than the basics a frame buffer isn't all that complex. A standard DRAM controller core to talk to memory, a set of FIFO's and a state machine to decide who does what when. If this is strictly for painting text and some basic graphics on the screen it's a relatively simple matter to double or triple buffer the interface you can render text/graphics in the background and flip between the live and background buffers during the vertical blanking period. S-100. Ah. The good old days when you could actually wire-wrap your own peripheral boards. Here's a data point to date me: I ran AutoCAD on an S-100 system with a separate S-100 math co-processor card and a 640K ram-drive card. Worked like a charm. Oh, yes, interaction was through a VT-100 terminal (the real deal) and a tablet with a wired puck. How many people on HN do you figure actually touched an IMSAI (outside a museum)?