Generate VHDL code from VHDL code

Its possible that you might be able to do this using a combination of Qsys _hw.tcl and generics.

Lets say I have a Qsys system that I can include or exclude an SPI device. That SPI device has an interface spi_selN, spi_clk, spi_mosi, and spi_miso.

Qsys will mangle the name slightly, lets say it adds the prefix spi_interface_XXX to all your signals. You could have a top-level like this:

generic (
    USE_SPI : boolean := true
    ...
g1: if (USE_SPI) generate
  -- Qsys system with SPI controller goes here
  ....
  -- Qsys SPI ports
  spi_interface_spi_selN => spi_selN,
  spi_interface_spi_clk   => spi_clk,
  spi_interface_spi_mosi => spi_mosi,
  ....
  ); -- end of Qsys ports
end generate;
g2: if (not USE_SPI) generate
  -- Qsys system without SPI controller goes here
  -- Unused SPI drivers
  spi_selN <= '1';
  spi_clk   <= '1';
  spi_mosi <= '1';
end generate;

You can then use a Tcl script to set the generic and generate the appropriate Qsys system.

Alternatively, you can use *exactly* the same Qsys system, and have the optional components interpret a generic that enables or disables them. That way those pins will exist on the Qsys component, but if they are not in use, then they will just drive deasserted levels ... just like the example here, but that logic would be inside each of your Qsys components.

Cheers,

Dave

--- Quote Start ---

But that would mean you will have to define every kind of component you might want to use in the system, right? So let's take a big numer of 100 devices, I would have to make generics for all those devices. That can't be what one would want to do, unless thats the only possible way.

--- Quote End ---

Sure you can come up with schemes where this would not make sense, I was just offering suggestions.

If you're designing a board for a specific application, and it has 100 components, then why would you not just instantiate all 100 components at once?

Its only the cases where you need to disable "some" of the components that you need to consider. But even that depends on what "disabled" means, eg., lets say you have two controllers that need to access the same I/O pins. You could either disable one or other components, or you could implement both and multiplex the pin functions.

Without knowing what your design is and what your real issue is, its hard to say much more. Other than to observe that you are likely making things more complicated than they need to be :)

Cheers,

Dave

Haha you might be right there, I am probably making things more complicated than they are. But it also probably isn't as easy to fix as I would think.

The problem is that the design has to work for every kind of board you can think of. So that means one design has a cyclone 3 and needs the spi, another design has a spartan 6 and needs to use ram, another design has a virtex 6 and needs to use the flash. I could go on with all the different designs that it needs to be compatible with, but that would be an endless list and I would probably forget some options. Maybe you can understand better what I want now?

An I just wanted to make sure if I understand the suggestions you make, so I don't assume it isn't possible with my design or I do assume it is possible and turns out to be the opposite.

I am more and more getting the idea, it cannot all be generated automatically or with a lot of my help. Since we are still working with hardware and we cannot use every design for every kind of hardware. But I also keep being stubborn that there must be some easy solution no one has thought of yet, or hasn't shared yet.

To summarize: I need a design that could fit on every kind of pcb, with any kind of fpga and always a module the fpga needs to 'talk' to.

If I finally made myself clear I am happy, if I haven't I probably have to try it a different way.

--- Quote Start ---

the design has to work for every kind of board you can think of. So that means one design has a cyclone 3 and needs the spi, another design has a spartan 6 and needs to use ram, another design has a virtex 6 and needs to use the flash.

--- Quote End ---

You're dreaming, sorry :)

--- Quote Start ---

I am more and more getting the idea, it cannot all be generated automatically or with a lot of my help.

--- Quote End ---

It can all be re-generated automatically using build scripts, however, you have to setup the infrastructure.

Here are your problems;

1. Mixing vendors

Altera, Xilinx, Lattice, Actel, etc. all have different IP blocks that implement the same function, eg., high-speed transceiver, that cannot be instantiated using generic VHDL/Verilog and inference.

Possible solution: You can create wrapper components and select the implementation either using a VENDOR generic, or you can use VHDL configurations.

2. Controlling the tools.

I've tested Altera (Quartus), Xilinx (ISE), and Lattice (Diamond) tools. They can all be scripted using Tcl.

3. Multiple boards, multiple I/O interfaces.

You have to create board-specific designs. Those board specific designs can however contain a re-usable general-purpose block.

For example, lets say you have a board with a GPIO header, and on-board I2C and SPI devices.

Since the I2C and SPI devices can never change, since they're physically soldered to the board, you can create I2C and SPI controllers in a block of registers in a Qsys system (or the other vendor equivalents), include a board ID register, a timestamp register, and a design register.

In the nominal design you can have a GPIO header control registers block.

So long as that register block always exists in the same location, software can identify which implementation is being accessed.

When a user customizes the design, they can delete the GPIO component, and replace it with their component.

4. Code organization

You need to think about how to arrange your code so that its easy to maintain. Here's what I have:

hdl/lib generic code, with Modelsim testbenches

hdl/examples example designs, eg., Qsys systems, may contain generated code, eg., Qsys may need to be run before you can simulate

hdl/boards board-specific folders

For example, here's a couple of designs in several board folders

hdl/boards/de0_nano/cyclone4/share/ source and scripts for the DE0-nano

hdl/boards/de0_nano/cyclone4/basic/ source and scripts for the DE0-nano 'basic' top-level design

hdl/boards/bemicro_sdk/cyclone4/share/ source and scripts for the BeMicro-SDK

hdl/boards/bemicro_sdk/cyclone4/basic/ source and scripts for the BeMicro-SDK 'basic' top-level design

hdl/boards/bemicro/cyclone3/share/ source and scripts for the BeMicro

hdl/boards/bemicro/cyclone3/basic/ source and scripts for the BeMicro 'basic' top-level design

hdl/boards/s4gxdk/stratix4/share/ source and scripts for the Stratix IV GX Development kit

hdl/boards/s4gxdk/stratix4/basic/ source and scripts for the Stratix IV GX Development kit 'basic' top-level design

The folder hierarchy is <board>/<device>/<design>, where device is an FPGA or CPLD on that particular board. Typically a board has several devices, eg., a MAX II system controller and a main FPGA.

Supporting multiple vendors complicates your component management; you have to decide whether you are going to support Altera Avalon, Xilinx OPB, Lattice Wishbone, ARM AXI, etc. Users will expect to be able to use vendor integration tools like Qsys, so you will have to create an Avalon interface to your SPI and I2C controllers, and then create an AXI interface for the AXI users, and a Wishbone interface for the Lattice users ... etc.

Just some ideas for you to ponder.

Cheers,

Dave

--- Quote Start ---

1. Mixing vendors

--- Quote End ---

Luckily I only have to support Altera and Xilinx for now, still different vendors, but might make it easier. I can't seem to find the IP blocks of Xilinx(Altera are the asmi blocks you need to use, right?), so I can make sure they have the same in and outputs. If they have it should be simple with configurations, or is it still easier to just change the entity name to the component that needs to be used with another script I was planning to make?

--- Quote Start ---

When a user customizes the design, they can delete the GPIO component, and replace it with their component.

--- Quote End ---

Good thing is, the user may not customize the design I created. All he has to do is to tell which components he wants to use and which pins are attached to those. This way the user doesn't even need to know how an FPGA works, as long as he knows how to shoot the program in it(and if it's possible to automate that, the user doesn't have to do that either).

--- Quote Start ---

You need to think about how to arrange your code so that its easy to maintain.

--- Quote End ---

I was thinking to arrange the code with at least folders FPGA and Components, maybe I need to think better and more about that also indeed.

Those hardware blocks like SPI, I2C, SRAM, DRAM, whatever you can think of, can always be implemented the same no matter what the board looks like or what FPGA is used right? Except for the memory components, they can be bigger or smaller of course. Or did I miss more?

--- Quote Start ---

Luckily I only have to support Altera and Xilinx for now, still different vendors, but might make it easier. I can't seem to find the IP blocks of Xilinx(Altera are the asmi blocks you need to use, right?), so I can make sure they have the same in and outputs. If they have it should be simple with configurations, or is it still easier to just change the entity name to the component that needs to be used with another script I was planning to make?

--- Quote End ---

Yes, at some level you can make the components look identical.

For example, since Altera and Xilinx both support AXI, I would recommend making every component have standard AXI interfaces as much as that seems reasonable. Before jumping into that though, I would first check whether there are good verification tools available for the AXI interface testing, eg., either from Altera or Xilinx, or from ARM.

By standardizing on an interface, you only have to generate a single component, rather than one per vendor.

--- Quote Start ---

Good thing is, the user may not customize the design I created. All he has to do is to tell which components he wants to use and which pins are attached to those. This way the user doesn't even need to know how an FPGA works, as long as he knows how to shoot the program in it(and if it's possible to automate that, the user doesn't have to do that either).

--- Quote End ---

What does your hardware target look like? There are very few interfaces where the user will just "shoot the program in it". Most FPGA designs need to be configured at power-on. This is especially true of low-cost designs, where you can't afford to have multiple FPGAs on a board.

--- Quote Start ---

I was thinking to arrange the code with at least folders FPGA and Components, maybe I need to think better and more about that also indeed.

--- Quote End ---

Download the Leon SPARC processor code from Gaisler, look at open cores, etc. See how others deal with it. I expect you would have an area for generic HDL, another for vendor-specific HDL (with wrappers to make it look generic, for use by the generic HDL), and an area for target devices.

--- Quote Start ---

Those hardware blocks like SPI, I2C, SRAM, DRAM, whatever you can think of, can always be implemented the same no matter what the board looks like or what FPGA is used right? Except for the memory components, they can be bigger or smaller of course. Or did I miss more?

--- Quote End ---

Right. You create parameterized components (that are customized by VHDL generics or Verilog parameters). You might actually have several implementations of similar components. Then under each vendors tool, eg., Altera Qsys, you create a _hw.tcl script to make it appear to the user that they are configuring the "SPI Controller", when in fact, they are really just selecting from one of several possible implementations.

Even if the "user" is you, it can make creating designs for target boards easier.

The main thing you want to do is create a dummy setup with a couple of boards from a couple of vendors and see if you can get it working, eg., have a blinking LEDs design built using vendor IP blocks, eg., an Altera LPM counter in the Altera design, and see if you can implement an identical Xilinx design, and all the associated infrastructure (generics on the parts, Tcl scripts for each tool, etc).

Cheers,

Dave

oh I had such a long story and didnt copy it when I wanted to send it:( forgot to sign in apperently:(

next try:

I'm trying to figure out what that axi thing is, I have been looking into the wrapper thing. Are those two comparable? Is it just that the axi thing is an already designed thing to make that wrapping easier?

The hardware is powered on when the device is loaded, I don't know what kind of information you would need further? I was thinking to speak to the vendors programming things, without the interface.

I will also look at the Leon SPARC processor code, I have been looking around at opencores already but need to do that some more.

A lot of advice again, which makes me help to understand what I want and can do and if you understand what I want.

Thanks for all the advice and efford:)

--- Quote Start ---

oh I had such a long story and didnt copy it when I wanted to send it:( forgot to sign in apperently:(

--- Quote End ---

I hate that when that happens (or more often the database crashes when you just finished typing ...)

--- Quote Start ---

I'm trying to figure out what that axi thing is, I have been looking into the wrapper thing. Are those two comparable? Is it just that the axi thing is an already designed thing to make that wrapping easier?

--- Quote End ---

Its a bus protocol, just like Altera's Avalon standard, and the OpenCores Wishbone standard. The AXI standard is an ARM standard.

--- Quote Start ---

The hardware is powered on when the device is loaded, I don't know what kind of information you would need further? I was thinking to speak to the vendors programming things, without the interface.

--- Quote End ---

Right, but you said the "user would shoot the program in it", but elsewhere you implied the user would be ignorant of the HDL. Of course, the user can still be ignorant of the HDL if they are just downloading a pre-compiled image.

--- Quote Start ---

A lot of advice again, which makes me help to understand what I want and can do and if you understand what I want.

Thanks for all the advice and efford:)

--- Quote End ---

You're welcome.

Cheers,

Dave

--- Quote Start ---

Its a bus protocol, just like Altera's Avalon standard, and the OpenCores Wishbone standard. The AXI standard is an ARM standard.

--- Quote End ---

Ah that makes sense. So that would mean I would have another layer in my design which I would call FPGA bus. Thats not that bad, but it also means I would have to make the FPGA blocks in a way they can be connected to that bus, right? Or could there be a possibility there already are the blocks to integrate the AXI standard?

--- Quote Start ---

Of course, the user can still be ignorant of the HDL if they are just downloading a pre-compiled image.

--- Quote End ---

Exactly! Thats what I want, I want to do all the work for the user, so that the user has its compiled image and can just push a button I made in my interface and it will be programmed in it. I am just not aware if it is possible to make such a thing, or if I would have to start quartus for example and let the user push the program button there.