Generate VHDL code from VHDL code

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.

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.

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

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

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

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.

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

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

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

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.