Generate VHDL code from VHDL code

[Altera_Forum]

Hello, 

I have been wondering for a while if it is possible to let some standard tool (like quartus, or ISE or maybe even a windows tool) generate a VHDL file from previous written VHDL code. For example when you have some different VHDL files you have written before, and theyre all reusable. Is it possible to say; I want these 3 files working together and now try and make a toplevel for me? Or do you have to write your own file in a different language that links them all together?  I hope it is somewhat clear, but I can understand that it might be too vague, so please ask questions that might help making my question clear.  Thanks in advance

[Altera_Forum]

You can write a top level in VHDL if you want. And SOPC Builder/QSys might be the closest thing to "auto generation" of a top level. But it still needs to know how you want things connected. 

 But your question is not very clear. Yes you can write a top level in VHDL to instantiate and connect any number of other VHDL modules.

[Altera_Forum]

I see I wasn't very clear.  

The problem is that one way or another, this toplevel is going to be generated automatically. If there is no tool to do such a thing, it would become a self written program that would read all the inputs and outputs from the components and than decide how these things are going to be connected. In some way it seems like an impossible thing to do, since it needs to be really general. Thats why I hoped there would be some kind of tool to do such a thing. So that I dont have to write 20 different toplevels, for all the different designs I want to make(designs that might only differ one component for example). I'm not sure if you could ''speak'' to qsys via TCL?  I try my best to make it less general, but it isn't as easy as i thought.

[Altera_Forum]

--- Quote Start ---   The problem is that one way or another, this toplevel is going to be generated automatically.   --- Quote End ---    Think of it slightly differently.   When you design a PCB and layout an FPGA, the pin functions of the FPGA are then fixed. You can create a single top-level design that represents all designs that will ever be used on the board. The pin names in this top-level design are then fixed and never change, so it makes creating .SDC constraints files a lot easier, since you only need to create them once and the pin names remain the same.  Your "designs" are then one layer below this top-level, and yes, you have to manually connect them to the top-level pins on the FPGA. There really is no automated way to do this, since a tool cannot guess how you want the signals connected.    --- Quote Start ---   it would become a self written program that would read all the inputs and outputs from the components and than decide how these things are going to be connected.   --- Quote End ---   There's really no way that this can work the way you think. Lets say I have some I/O blocks, some memory, an SPI controller, and an I2C controller IP blocks. How can a program decide how these should be connected? You have to tell it, right? That is the purpose of SOPC Builder and Qsys. That tool produces a top-level component that describes the I/O of that one component. That component might be the top-level, or it might be one of many components in a design.  Bottom line, you'll have to manually connect wires from your components to the top-level design that represents your FPGA pins.    --- Quote Start ---   In some way it seems like an impossible thing to do, since it needs to be really general. Thats why I hoped there would be some kind of tool to do such a thing. So that I dont have to write 20 different toplevels, for all the different designs I want to make(designs that might only differ one component for example). I'm not sure if you could ''speak'' to qsys via TCL?  I try my best to make it less general, but it isn't as easy as i thought.  --- Quote End ---    If the top-level design that represents the FPGA is the same, and the pins on the Qsys component remain the same, then you can simply regenerate the Qsys instance. However, if your Qsys system has different pins, then those pins need to go somewhere, and you need to route them.  If it was easier to control the pin names on the Qsys system, then you could map the top-level Qsys pins to the FPGA pins, however, your constraints file would have the top-level pin names change ...  Take a look at the design files in this tutorial;  http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial  In this design, one Qsys file is used for multiple boards. I know, you probably want something slightly different, but take a look and get ideas.  If you get stuck, ask questions, or describe your design(s) in more detail. Perhaps all you really need is some generate statements.  Cheers, Dave

[Altera_Forum]

Thanks for the extensive explanation Dave. 

 It is possible to import a pinmapping right?  Than I would think the problem with not knowing how to put the signals together would be over, or am I thinkiing about this a little too easy? Let's say at least the inputs and outputs from the toplevel are always the same, but only the signalls vary with different components. I always have a component of type A, this component also always has the same in and outputs for every different component(so it only differs in architecture). And I also always have a component of type B, same inputs and outputs for every different component again. Now I always want to connect a (yet undifined)component of type C, to a component of type A. And a (yet undifined)component of type D also connects to type A and B. So we've got: C<>A<>D<>B Always Is it than still not possible to say: ok since we have type A we need to connect it with type C and we need to do it this way: input Ax <= output Cx, input Ay <= output Cy  I am also reading the tutorial, so maybe I will get those answers there too

[Altera_Forum]

--- Quote Start ---   It is possible to import a pinmapping right?    --- Quote End ---    Sure, but there still has to be a one-to-one mapping between the pin names in your top-level HDL entity and your pin mapping script or spreadsheet. If you look at the tutorial source, you will see that correspondence, i.e., a top-level HDL file and a Tcl script with pin constraints, where those constraints use the same name as the top-level HDL. If your top-level HDL is generated by Qsys, then the top-level pin names change depending on how you name the components in the system.    --- Quote Start ---   Than I would think the problem with not knowing how to put the signals together would be over, or am I thinking about this a little too easy? Let's say at least the inputs and outputs from the top-level are always the same, but only the signals vary with different components. I always have a component of type A, this component also always has the same in and outputs for every different component (so it only differs in architecture). And I also always have a component of type B, same inputs and outputs for every different component again. Now I always want to connect a (yet undefined) component of type C, to a component of type A. And a (yet undefined) component of type D also connects to type A and B. So we've got: C<>A<>D<>B Always Is it than still not possible to say: ok since we have type A we need to connect it with type C and we need to do it this way: input Ax <= output Cx, input Ay <= output Cy   --- Quote End ---    This problem can be solved using VHDL configurations.  In VHDL a 'component' definition tells the compiler what pins a component has. Using a configuration you can map an entity to a component.  In your code, you can write the code to include known components A and B, and connect them to 'component' definitions for C and D. Then you use a configuration to map C and D to their implementations.  I posted a VHDL configurations example in this thread:  http://www.alteraforum.com/forum/showthread.php?t=30414&page=2  Take a look at VHDL configurations and let me know if they meet your requirements. If they don't, we can discuss using generate statements, generics, and Tcl.  Cheers, Dave

[Altera_Forum]

So ive read and done(some parts of) the tutorial but I didn't quite get how it is all connected to each other or not. I can see 3 different boards and a map called share. I is correct you have to build the quartus or the spoc system only once and after that just change the tcl scripts to change something? But every board has its own tcl scripts, so you would have to write a tcl script for every kind of board you want to use? Or am I not getting the idea of the files at all? 

 I have been examining example 3 of the thread. As far as I understand the configurations examples, it seems like you would have to use a same kind of component again and again to give the configuration VHDL file any value. So this way I wouldnt be able to change my component C from an SPI ip block to a RAM ip block for example, since than those in and outputs don't make sense anymore. Or is there some way to make this happen too with configurations, or would I have to declare in that file every kind of ip component I want to use?  I'm pretty lost now in this forest of possibilities or non-possibilities.

[Altera_Forum]

--- Quote Start ---  So ive read and done(some parts of) the tutorial but I didn't quite get how it is all connected to each other or not. I can see 3 different boards and a map called share. I is correct you have to build the quartus or the spoc system only once and after that just change the tcl scripts to change something? But every board has its own tcl scripts, so you would have to write a tcl script for every kind of board you want to use? Or am I not getting the idea of the files at all?   --- Quote End ---    Each board has its own folder containing a top-level design file. The same SOPC system is used in each design, however, the XML description is re-processed for each project. This allows Quartus to create whatever hardware is specific to a particular FPGA architecture. For example, each FPGA has memory, but the memory can be different between architectures, so you need to process the SOPC file on a per board basis.    --- Quote Start ---   I have been examining example 3 of the thread. As far as I understand the configurations examples, it seems like you would have to use a same kind of component again and again to give the configuration VHDL file any value.   --- Quote End ---   You need to pick up a VHDL book and look at what configurations are. A configuration can be used to map an 'entity' to a 'component'. If the port names on the entity and component are identical, then the mapping is trivial. If the two components are similar, but have different ports, then you can map which port connects to what. I'm not saying that these are the solution to your problem, I'm just suggesting that they might be. If you're getting confused by all the options, just skip it.    --- Quote Start ---   So this way I wouldnt be able to change my component C from an SPI ip block to a RAM ip block for example, since than those in and outputs don't make sense anymore. Or is there some way to make this happen too with configurations, or would I have to declare in that file every kind of ip component I want to use?   --- Quote End ---   As I said above. If your SOPC/Qsys system has the same I/O then you do not need to change anything. As soon as you change the I/O, then you have different components, so naturally you need to have different instantiations of the components. However, in that case you can use a generic.  For example,   entity top_level is generic ( DEVICE : integer := 0 ); port ( rstN : in std_logic; clk : in std_logic; pin_in : in std_logic_vector(7 downto 0); pin_out : out std_logic(7 downto 0) ); component a is port ( rstN : in std_logic; clk : in std_logic; a_in : in std_logic; a_out : out std_logic ); component b port ( rstN : in std_logic; clk : in std_logic; b_in : in std_logic_vector(1 downto 0); b_out : out std_logic_vector(1 downto 0) ); g1: if (DEVICE = 0) generate u1: a port map ( rstN => rstN, clk => clk, a_in => pin_in(0), a_out => pin_out(0) ); pin_out(7 downto 1) <= (others => '0'); end generate; g2: if (DEVICE = 1) generate u1: b port map ( rstN => rstN, clk => clk, b_in => pin_in(1 downto 0), b_out => pin_out(1 downto 0) ); pin_out(7 downto 2) <= (others => '0'); end generate;   Note how this design has a common top-level, and two separate possible implementations, with the implementation selected by a generic.  Perhaps this will give you some idea ...  Cheers, Dave

[Altera_Forum]

Thanks for the great explanations.  

I indeed had the intention to get and read/search my VHDL book, but I keep forgetting about it. This week I must take that book and go and read it, after that maybe I'll have more or other questions and might be able to draw a bigger picture of what I want to do and how that might be possible. I think I at least have an idea where to search for, what to read and what to specify. So for now it will be best to go and read that book and don't ask any questions anymore before I have done that. Thanks again:)

[Altera_Forum]

--- Quote Start ---  Thanks for the great explanations.  --- Quote End ---   You're welcome.    --- Quote Start ---    I indeed had the intention to get and read/search my VHDL book, but I keep forgetting about it. This week I must take that book and go and read it, after that maybe I'll have more or other questions and might be able to draw a bigger picture of what I want to do and how that might be possible. I think I at least have an idea where to search for, what to read and what to specify. So for now it will be best to go and read that book and don't ask any questions anymore before I have done that.   --- Quote End ---   While you read your book, make sure to write code, and compile it using Modelsim and Quartus. That will help in understanding the code, and will ensure the code is valid (I have good books - good explanations, with bad code).  Cheers, Dave

[Altera_Forum]

I've done a little reading in my book, but the chapter Configurations gives me a lot less information about how to use it than you did. I will still look through my book to see if I can find something usefull, but I didn't find what I was looking for yet unfortunately:( 

 I've also thought some more about what my program should look like. And it seems like Iv'e got some components I can bind together because they indeed always have the same in and outputs. So the only thing I would need to change is the entity name, since that will get the right architecture also. One problem fixable.  But than comes trouble, I also have components with inputs and outputs I can't specify yet so I can't make the signals for that either. If I would use the package option, I am still not able to do such things right? I can't make a "component a port();" and than hope all those in and outputs will be some magical way connected to the right signals in the toplevel, right?  Than I also have some components where some in and outputs must be present and others are extra, I thought that would be fixable in the same way as my problem above, or maybe even easier. But I wouldn't know how, maybe I need to look some more into the packages option.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

--- 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

[Altera_Forum]

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.

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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?

[Altera_Forum]

--- 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

[Altera_Forum]

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:)

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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.