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]

--- Quote Start ---  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?   --- Quote End ---   You would design your components with "standardized interfaces". Unfortunately, there are several standards, so you have to decide whether to choose one, or multiple.    --- Quote Start ---   Or could there be a possibility there already are the blocks to integrate the AXI standard?   --- Quote End ---   AXI is one of the standards that both Altera and Xilinx support. Using this standard should make supporting both vendors easier - even if the internal implementation had to have some vendor-specific logic.    --- Quote Start ---   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.  --- Quote End ---   It depends on how you design your hardware. Its very easy to load binary configurations created by Quartus at a later point in time.  For example, the FPGAs on +100 of these boards are dynamically reconfigured  http://www.ovro.caltech.edu/~dwh/carma_board/  without ever using Quartus. Quartus is used to create the configuration images, but then they are stored on a filesystem for use when the FPGAs are to be reconfigured.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Download the Leon SPARC processor code from Gaisler  --- Quote End ---   Wow I din't think that processor code would be so big. Or maybe I am looking into more than just the processor. I've got the idea I have about a gig or more on just manuals and stuff. I don't know where to start, so I have been looking around in the files. But most feel like they have been created in some way I haven't founf yet. I think I have enough to read for about a year or so now?    --- Quote Start ---  You would design your components with "standardized interfaces".  --- Quote End ---   Ah, but than I believe I am supposed to do those things via Wishbone. The good thing is, I don't have to design all the files that are going to be used. So I can define what they should look like(as far as it's reasonable ofcourse), which will make it easier to make a more general approach I believe. I need to invent a good design which will cover a lot of devices, without the need of too much reconfiguring I would assume. So that's also a challange. Oh and if it's not possible to use the wishbone, it must also be possible to choose another already designed interface. But thats a thing for the user to choose, so the user can choose another interface if he would like that for some reason.    --- Quote Start ---  For example, the FPGAs on +100 of these boards are dynamically reconfigured  --- Quote End ---   So if I understand the documentation correctly, the configuration files of the FPGA's are put in a fifo somewhere on the board. And read some time when they are told to be reconfigured?  I have just found out the files Quartus standard creates to program your device aren't the only way indeed to programm the device. It is sometimes hard to remember there are more ways to do something, what you have always done some specific way. I must also say it isn't easy for me to walk away from the known path, so I didn't like the other ways to program the device. But it is sure a good thing to know.

[Altera_Forum]

--- Quote Start ---  Wow I din't think that processor code would be so big. Or maybe I am looking into more than just the processor. I've got the idea I have about a gig or more on just manuals and stuff. I don't know where to start, so I have been looking around in the files. But most feel like they have been created in some way I haven't found yet. I think I have enough to read for about a year or so now?   --- Quote End ---   This should give you an idea of how "complex" things can become :)    --- Quote Start ---   Ah, but than I believe I am supposed to do those things via Wishbone.   --- Quote End ---   What do you mean "I believe"? You have either been asked to do it or not. There should be no uncertainty.    --- Quote Start ---   The good thing is, I don't have to design all the files that are going to be used. So I can define what they should look like(as far as it's reasonable ofcourse), which will make it easier to make a more general approach I believe.   --- Quote End ---   I'm afraid you are not being specific enough. There is no one general approach, there are many many approaches. As I commented earlier, there are many standard buses. If you plan on supporting; AXI, Avalon, and Wishbone, then you will have a lot of work to do.    --- Quote Start ---   I need to invent a good design which will cover a lot of devices, without the need of too much reconfiguring I would assume. So that's also a challange.   --- Quote End ---   You don't get to invent anything. Altera, Xilinx, and Lattice have already defined the bus protocols their respective tools understand. If you want people using those tools to use your components, then you have to supply the bus interfaces acceptable to those vendors.    --- Quote Start ---   Oh and if it's not possible to use the wishbone, it must also be possible to choose another already designed interface. But thats a thing for the user to choose, so the user can choose another interface if he would like that for some reason.   --- Quote End ---   No, its not up to the user to decide. The decision has already been made by the FPGA vendor.     --- Quote Start ---   So if I understand the documentation correctly, the configuration files of the FPGA's are put in a fifo somewhere on the board. And read some time when they are told to be reconfigured?   --- Quote End ---   No. The configuration files are transferred from a network filesystem or flash. The FIFOs are in there to decouple clock domains and implemented data flow control.    --- Quote Start ---   I have just found out the files Quartus standard creates to program your device aren't the only way indeed to programm the device. It is sometimes hard to remember there are more ways to do something, what you have always done some specific way. I must also say it isn't easy for me to walk away from the known path, so I didn't like the other ways to program the device. But it is sure a good thing to know.  --- Quote End ---    There are indeed multiple methods to configure devices. Not all are easily available. For example, if a user has a board plugged into their PC, it might not be possible to access the JTAG connector. If that same board is using the FPGA as the PCIe interface, then not all FPGAs support being reprogrammed without cycling power of the user PC ...   Cheers, Dave

[Altera_Forum]

Damn you really have to do the ''remember me'' option when logging in when typing long messages. At least this time my message didn't leave me and I had also copied it:) 

   --- Quote Start ---  This should give you an idea of how "complex" things can become   --- Quote End ---   It sure does, it keeps surprising me how people come up with really big or complex designs. I sometimes think; they must have been breeding on these things for years. How else would you think of such a thing? It's amazing.    --- Quote Start ---  What do you mean "I believe"?  --- Quote End ---   I believe, because I still wasn't sure if it was the same. But now I am pretty sure it has to be done that way.  I think I would never say I am 100% confident that it is true.    --- Quote Start ---  If you plan on supporting; AXI, Avalon, and Wishbone, then you will have a lot of work to do.  --- Quote End ---   Supporting Wishbone is the 'only' requirement for now(I have half a year to work on this), so that would mean every component interfacing with the wishbone needs to have signals like ADR_o/ADR_I, Dat_i/Dat_o etc. I think you understand which signals I mean. So if I define they have to have these signals, or else I will not support that block. Than I can put those signals in the right place easier, than when I need to support all and everything. Those Ip block that are going to be used have to be changed anyway, so they can be changed in the way I want them.(as far as it is possible ofcourse, I cannot just remove a pin the device needs to work properly for example)    --- Quote Start ---  If you want people using those tools to use your components, then you have to supply the bus interfaces acceptable to those vendors.  --- Quote End ---   I am not sure if you don't understand what I have to make, or I don't understand what you mean. I think you mean by this I have to supply the components to the user so that they can play with their FPGA in a way you do when you are figuring out HDL's. So they try to put some component in their design and hope it workd, the way they have connected it. But what I need to supply is really the whole design, so other people will make the ip-blocks compatible to my program. And my program needs to use these components to make a design, so that the user can put it in their FPGA and see what happens.    --- Quote Start ---  No, its not up to the user to decide. The decision has already been made by the FPGA vendor.   --- Quote End ---   It is not only the FPGA vendor, but also the makers for the IPblocks. So since the IPblocks have to comply with my definitions, one can make a component that supports one of the other bus protocols instead of wishbone. But that was an extra part, and I think it is hard enough to do it without that extra buschoice, so maybe I could better leave that part where it is.    --- Quote Start ---  The FIFOs are in there to decouple clock domains and implemented data flow control  --- Quote End ---   Ah that makes sense, I will read it once again with that information and see if I will understand it the right way.    --- Quote Start ---  For example, if a user has a board plugged into their PC, it might not be possible to access the JTAG connector  --- Quote End ---   Do you mean with the JTAG connector, that pin on the FPGA itself? Or that connector to put the cable on/in, so that it can be boundary-scan tested?    --- Quote Start ---  If that same board is using the FPGA as the PCIe interface, then not all FPGAs support being reprogrammed without cycling power of the user PC  --- Quote End ---   What do you mean with ''cycling power'' of the user PC? turning the PC on and of? If so, why would that be neccesary?  I hope I didn't mess up the explanations so that you now really don't have a clue anymore about what I am doing. But the answers you give help a lot too, so that might not be the worst case.

[Altera_Forum]

This discussion is getting fairly long and complex. I'll just focus on the interface issue for now. 

   --- Quote Start ---   Supporting Wishbone is the 'only' requirement for now   --- Quote End ---    Who made this requirement?  You need to realize that if you create a component that is Wishbone compliant, that it is not compatible with Altera Qsys and it is not compatible with Xilinx tools. It would however be compatible with Lattice tools (and their Mico32 soft-core processor).  This is why I said that the vendors have already made the interface decision for you. Qsys supports Avalon components, and more recently AXI components.  Lets take something as simple as an on-chip RAM. The Avalon interface and Wishbone interface are very similar, if not identical. However, the naming convention for the entity ports is different, so at a minimum you would want to adhere to the interface standard and name the signals appropriately. For example, an Avalon-MM slave single-port RAM interface is   entity avs_single_port_ram is generic ( AWIDTH : integer := 5; BWIDTH : integer := 4; DWIDTH : integer := 32 ); port ( -- Reset and clock rstN : in std_logic; clk : in std_logic; -- Avalon Slave Interface avs_read : in std_logic; avs_write : in std_logic; avs_addr : in std_logic_vector(AWIDTH-1 downto 0); avs_byteen : in std_logic_vector(BWIDTH-1 downto 0); avs_wrdata : in std_logic_vector(DWIDTH-1 downto 0); avs_rddata : out std_logic_vector(DWIDTH-1 downto 0); avs_rdvalid : out std_logic; avs_wait : out std_logic ); end entity;   but the equivalent Wishbone part would have a different prefix, and _i and _o suffices on the signals.  The major issue you face with using Wishbone in Altera tools is that you lose the ability to use Qsys. Qsys is useful in that it creates all the multi-master/multi-slave address-decoding and arbitration logic. Sure you can create it yourself, but Qsys saves you having to.  Since you say you only have half a year to complete this, you first need to write up the "Project Deliverables", i.e., define the minimum set of features you expect to implement. In that same document you should also describe how this code fits into the larger picture, but you need to focus on a subset first, otherwise you will get lost in the complexity.  What you should do next is to write up a document that distills your project goal. Take some of this discussion and use it to fill in details. Put "TODO" where you are missing information. Post it here on the forum, or email it to me directly and I'll read through it. Make sure to include some use-cases of example users and how you expect them to use your code, eg., what is their hardware, how are they supposed to download a new image to their board, etc.  Cheers, Dave

[Altera_Forum]

I got a great inspiration yesterday when I was reading about AMBA, it sounded so familiar but I didn't know why. Well now I know, the guys before me have been looking into the different interfaces to use and which one was best. So they have decided it was going to be Wishbone with all of their explanations and stuff. 

   --- Quote Start ---  The major issue you face with using Wishbone in Altera tools is that you lose the ability to use Qsys. Qsys is useful in that it creates all the multi-master/multi-slave address-decoding and arbitration logic. Sure you can create it yourself, but Qsys saves you having to.  --- Quote End ---   I am not sure if I agree on that. I prefer not to rely on any tools used by vendors, if I can do it myself and know EXACTLY what will happen. Since those tools can change, or might not work properly, I cannot do anything about such a thing. But when it's in the program/design I made, I can look for the problem and try to solve it. With using Qsys you would have to find a workaround and know which version they have. Ofcourse when it is all my design, it might have even more problems than Qsys, but at least I would have one standard tool to use for every vendor. That is also why I try to do things without all those vendor specific tools, unless it is really not possible.  So in short: there are already a few designs made by hand, but done in a way they are most similiar. Wishbone has been chosen as the interface bus. Every design has a specific FPGA block, uses the wishbone and has some component to work with. User chooses FPGA and component, I know these blocks, put the design together and compile it with the vendor specific tool. User may have the option to say when the design needs to be programmed in the FPGA, or it is done right away if possible. I think thats about it

[Altera_Forum]

It sounds like you've got a good handle on the trade-offs. 

 One thing I did not like about Wishbone when I last looked at it, was there was no decent bus functional model (BFM) support needed for creating testbenches (the Wishbone equivalent of Altera's Verification IP suite).  You really need to have a BFM to build components. Sure you can write a BFM and then create your components, however, if you incorrectly interpreted the specification, then you will code that error into both your master and target BFMs. Its usually a little nicer if the BFM is already available.  Cheers, Dave

[Altera_Forum]

I am finally getting the idea about what is supposed to happen and what would be a solution. 

 I must say I have never made a testbench before, the way to test and verify my code works was with doing little tests with modelsim and try and see what happens when I programm the chip.   A testbench is just a simulationmodel, build to verify what your design does, right? Some automated way to check every possibility?  Since I am not familiar with testbenches, I am not sure if I would need them. Because the design has to do what it has to do and I assume the IP blocks are correct. So that means the only thing that needs to be tested is if the blocks are connected in the right way.  I must really thank you for the advice and options, I think I wouldn't have understand my problem this far without it:) Who would have thought you could learn so much off a forum

[Altera_Forum]

--- Quote Start ---   I must say I have never made a testbench before, the way to test and verify my code works was with doing little tests with modelsim and try and see what happens when I programm the chip.   A testbench is just a simulationmodel, build to verify what your design does, right? Some automated way to check every possibility?  Since I am not familiar with testbenches, I am not sure if I would need them. Because the design has to do what it has to do and I assume the IP blocks are correct. So that means the only thing that needs to be tested is if the blocks are connected in the right way.   --- Quote End ---   You can never assume anything. You should learn how to do things correctly from the start.  HDL should be written like software (Agile, Test Driven Development). It should work sort of like this;  1. Create a basic design (document, timing diagram, etc) 2. Create your synthesizeable HDL 3. Create your testbench to test the HDL 4. Use code coverage to make sure every logical path through your design is exercised correctly. 5. Integrate into a larger design 6. Synthesize and test in hardware 7. Use an automated build system or continuous integration tool to check that your component always works, eg., if it is a component created from other components, and you change an underlying component, then check that those changes did not break anything.  This requires using testbenches that check themselves, eg., write something to a register, poll until the controller is done, check the results, etc.    --- Quote Start ---   I must really thank you for the advice and options  --- Quote End ---    You're welcome.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  You can never assume anything  --- Quote End ---   I just meant to say, that I don't have the information about what this exact component should do. So I assume, that whatever he does, is supposed to work. At least for now, to keep things simple. Later on I could think about: but wait, what if this component isn't doing the right thing, I must at least tell the user it will not work.  Now my biggest problem is to find a way to connect those different blocks to the right signals. Since my blocks aren't as similiar as I thought at first, which means I am not able to use configurations. The blocks have a different amout of inputs and outputs. I was hoping I could make some template and just fill in the right words in the right places(that will probably be done in an other language). But for now I think the design is to complex for such a solution.  So the step creating the synthasizable HDL isn't as far as I thought it would be yet, or maybe even the basic design.

[Altera_Forum]

--- Quote Start ---  I just meant to say, that I don't have the information about what this exact component should do.   --- Quote End ---   Why not? Even if a component is a black-box component provided by someone else, you can still write a testbench to ensure that it adheres to its interface standard, eg., if I wanted to check that an Altera Avalon-MM slave component worked correctly, I would use the Avalon-MM verification IP suite to test it.    --- Quote Start ---   but wait, what if this component isn't doing the right thing, I must at least tell the user it will not work.   --- Quote End ---   Any how do you tell if the component isn't doing the right thing if you do not test it?  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  if I wanted to check that an Altera Avalon-MM slave component worked correctly, I would use the Avalon-MM verification IP suite to test it  --- Quote End ---   That sounds not so weird indeed. The interface should be able to be tested without knowing what the exact component does. But I would never know if the answer the component supplies is of any logical value, unless I have written the design myself and know when it should give output y with input x. Thats where I was thinking.    --- Quote Start ---  Any how do you tell if the component isn't doing the right thing if you do not test it?  --- Quote End ---   That was the line where I was thinking about when I can start thinking about that testbench. Since I am still a bit stuck to design the thing itself, I cannot write a testbench yet. Because than I would have to know the exact design and think about how to define my generated design works.  How weird is it that I am thinking about using another language to read the entity inputs and outputs to know which ones I need to put in my toplevel? So at that point I know which files i need to include, so I also know which entities. But I don't know which inputs and outputs the entity has and how can I connect this component if I don't know the in or outputs? Or am I overseeing some features of VHDL? In my understandings I can use the generates when I already have instantiated the components and the same with configurations.

[Altera_Forum]

I thought I should say I have made my program very different than what I thought was possible. 

I think indeed it is not possible, or very hard, to generate such a project all with just VHDL. So I had made a program which could make such a design, I think that is possible in any software language. I am not quite sure if it would be possible if the designs dont have any relations with each other. Main point is indeed that you really need to know exactly what kind of designs need to be generated, otherwise you keep writing the wrong things and can't figure out whats the way to deal with it.  I didn't have time to write a testbench, so it is only 'tested' via the RTL design.  Thanks again Dave for the input you have given, maybe I haven't used the things you mentioned, but I sure learned a lot:)

[Altera_Forum]

--- Quote Start ---  I thought I should say I have made my program very different than what I thought was possible.  --- Quote End ---   To some degree this is why writing an example, or prototype, is a good idea ... your ideas evolve as you write code.    --- Quote Start ---   I didn't have time to write a testbench, so it is only 'tested' via the RTL design.   --- Quote End ---   Take the time to write a testbench for each module. If each module has a standardized interface, eg., Avalon-MM or AXI, then once you have written the first testbench, the others are very simple.    --- Quote Start ---   Thanks again Dave for the input you have given, maybe I haven't used the things you mentioned, but I sure learned a lot:)  --- Quote End ---    You're welcome. I'm not bothered if you do not follow my advice, but eventually you'll figure out that some of it is good :)  Cheers, Dave