Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Request for feedback: proposed new Perl modules to aid VHDL projects

Reply
Thread Tools

Request for feedback: proposed new Perl modules to aid VHDL projects

 
 
Mike Treseler
Guest
Posts: n/a
 
      02-27-2006
Martin Thompson wrote:
> "Mike Treseler" <(E-Mail Removed)> writes:
>>I use vhdl-mode macros from the command line in my test scripts.
>>You could borrow a few features from it.

> Hi Mike,
> I'm intrigued - what do your test-scripts do that vhdl-mode helps
> with?


QA on a CVS repository.
I do a clean checkout then invoke an emacs macro
something like this:
emacs -f makemake
where the function below is declared in my ~/.emacs:

(defun makemake() "Generate Makefile from command line"
(interactive)
(vhdl-mode)
(vhdl-speedbar)
(vhdl-set-project "qa")
(speedbar-change-initial-expansion-list "vhdl project")
(vhdl-generate-makefile)
(kill-emacs)
)


-- Mike Treseler
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      02-27-2006
Allan Herriman wrote:

> The instantiation in your source code looks pretty much the same.
> my_label : entity my_lib.my_entity
> port map(...);
> or
> my_label : entity my_lib.my_entity(my_architecture)
> port map(...);


Thanks for the soapbox Allen.

I had forgotten about that second form.
Note that if I ever had a
reason to select architectures,
the direct method shown above
is much simpler and easier to read
than the equivalent configuration.

> Pros:
> - You don't need a component declaration.


Yes. Components are a big annoyance for me in dealing
with code by others. Why do double maintenance
on all the sub-entity port lists to maintain
default binding when no configurations or black-boxes are
used? Doooh!

> Cons:
> - You can't apply a configuration to this instantiation.


This feature is rarely used for synthesis.
For testbenches, I prefer generic options.

> - The entity declaration must already be compiled into the library
> prior to compiling the architecture which instantiates the entity.


If am blocking out a new design from the top,
I can just as easily declare and
instance the real entities with null architectures
to make my top-down block diagram.

With a top-down design using unbound components
I have to ignore binding warnings
until the real entities exist, and
then I have to maintain the component
declarations forever because no one
ever has the heart to delete a venerable
component for a direct instance.

> - It doesn't work with black boxes.


With the exception of analog things
like PLLs, most of the black boxes I see
could be replaced with a few lines of code.

-- Mike Treseler
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      02-27-2006
Mike Treseler wrote:
> Allan Herriman wrote:
>
>> The instantiation in your source code looks pretty much the same.
>> my_label : entity my_lib.my_entity
>> port map(...);
>> or my_label : entity my_lib.my_entity(my_architecture)
>> port map(...);

>
> Thanks for the soapbox Allen.

Allan

Sorry.

-- Mike
 
Reply With Quote
 
Allan Herriman
Guest
Posts: n/a
 
      02-28-2006
On Mon, 27 Feb 2006 10:20:49 -0800, Mike Treseler
<(E-Mail Removed)> wrote:

>Allan Herriman wrote:
>
>> The instantiation in your source code looks pretty much the same.
>> my_label : entity my_lib.my_entity
>> port map(...);
>> or
>> my_label : entity my_lib.my_entity(my_architecture)
>> port map(...);

>
>Thanks for the soapbox Allen.
>
>I had forgotten about that second form.
>Note that if I ever had a
>reason to select architectures,
>the direct method shown above
>is much simpler and easier to read
>than the equivalent configuration.
>
>> Pros:
>> - You don't need a component declaration.

>
>Yes. Components are a big annoyance for me in dealing
>with code by others. Why do double maintenance
>on all the sub-entity port lists to maintain
>default binding when no configurations or black-boxes are
>used? Doooh!
>
>> Cons:
>> - You can't apply a configuration to this instantiation.

>
>This feature is rarely used for synthesis.
>For testbenches, I prefer generic options.
>
>> - The entity declaration must already be compiled into the library
>> prior to compiling the architecture which instantiates the entity.

>
>If am blocking out a new design from the top,
>I can just as easily declare and
>instance the real entities with null architectures
>to make my top-down block diagram.
>
>With a top-down design using unbound components
>I have to ignore binding warnings
>until the real entities exist, and
>then I have to maintain the component
>declarations forever because no one
>ever has the heart to delete a venerable
>component for a direct instance.
>
>> - It doesn't work with black boxes.

>
>With the exception of analog things
>like PLLs, most of the black boxes I see
>could be replaced with a few lines of code.


Black boxes are also useful for mixed language designs (e.g.
instantiating a Verilog module in your VHDL) or for instantiating IP
cores.
In the past I have used them when independently compiling parts of the
hierarchy. I think I only ever did that when confronted with
synthesiser bugs, and I haven't had to use that trick for years.

Regards,
Allan
 
Reply With Quote
 
Michael Attenborough
Guest
Posts: n/a
 
      02-28-2006
"Mike Treseler" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Note that if I ever had a
> reason to select architectures,
> the direct method shown above
> is much simpler and easier to read
> than the equivalent configuration.


I'm in the process of switching from graphical design entry to text-only
(which is what inspired me to write these Perl modules) and I'm feeling my
way around the best way to use configurations.
So far, I am using them for two things:
1) Selecting between a fast RAM-block model which uses integer variables for
data storage and a slow-but accurate FPGA vendor's model
2) Switching the testbench's device-under-test between the RTL and the
gate-level model.

Configuration declarations don't seem to be serving me well for either
case...
1) Including all the hierarchy information to specify where the RAM blocks
are instantiated is a real pain, what with having to include all the entity
and instance names and generates.
2) This seemed good, but I couldn't actually get it to work because the RTL
had generics but the GLM did not. While a configuration declaration lets
you change the generic and port mapping, it doesn't seem to let me specify
"no generics" for an instantiation: "generic map ( )" is an error.

And if I'm considering configuration specifications instead, which means I
need to edit source recompile to change the architecture selection, it seems
I might as well use direct instantiation.
Using a preprocessor could be a nice way to control this (although it still
needs a recompile): I could have a file which defines macros for the RAM
architecture that I want, and include in any file where I instantiate a RAM
block.

in uart.vhd:
#include "arch_config.vhdh"
...
txfiforam : entity ram.dpram(RAM_ARCH) generic map (...

in arch_config.vhdh:
#define RAM_ARCH fast_int_model

> Yes. Components are a big annoyance for me in dealing
> with code by others. Why do double maintenance
> on all the sub-entity port lists to maintain
> default binding when no configurations or black-boxes are
> used? Doooh!


<salesman_mode> If you were using my build system, you would just need to
replace their component declaration for uart.switch_uart with "--<
component uart.switch_uart >--", for example, and no further maintenance
would be needed, or indeed any manual replacement of instantiations by
direct instantiation. </salesman_mode>

> > Cons:
> > - You can't apply a configuration to this instantiation.

>
> This feature is rarely used for synthesis.
> For testbenches, I prefer generic options.


Do you mean you would put in an "if MY_GENERIC=1 generate..." to select
between architectures? That's an idea, for testbenches at least.

Michael A


 
Reply With Quote
 
Martin Thompson
Guest
Posts: n/a
 
      02-28-2006
Mike Treseler <(E-Mail Removed)> writes:
<some things you can do with vhdl-mode>

Thanks - another tool for the box! And another reason I'm glad I
chose emacs as my editor...

Cheers,
Martin

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      02-28-2006
Michael Attenborough wrote:
> "Mike Treseler" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>Note that if I ever had a
>>reason to select architectures,
>>the direct method shown above
>>is much simpler and easier to read
>>than the equivalent configuration.

>
> I'm in the process of switching from graphical design entry to text-only
> (which is what inspired me to write these Perl modules) and I'm feeling my
> way around the best way to use configurations.
> So far, I am using them for two things:
> 1) Selecting between a fast RAM-block model which uses integer variables for
> data storage and a slow-but accurate FPGA vendor's model
> 2) Switching the testbench's device-under-test between the RTL and the
> gate-level model.


I expect that either of these could be handled
using a boolean generic selecting
one of two direct instances in the testbench.
Something like
IF fast_c generate ...
IF not fast_c generate ...

> While a configuration declaration lets
> you change the generic and port mapping, it doesn't seem to let me specify
> "no generics" for an instantiation: "generic map ( )" is an error.


You could assign generic defaults for this
case and and just leave out the map.

>>>Cons:
>>>- You can't apply a configuration to this instantiation.

>>This feature is rarely used for synthesis.
>>For testbenches, I prefer generic options.

>
> Do you mean you would put in an "if MY_GENERIC=1 generate..." to select
> between architectures? That's an idea, for testbenches at least.


I don't see why not.
I rarely do gate sims, but this might make a good example.
I do use generics to select testbench tests from the command line.
That works fine.

-- Mike Treseler
 
Reply With Quote
 
Allan Herriman
Guest
Posts: n/a
 
      03-01-2006
On Tue, 28 Feb 2006 11:09:57 -0000, "Michael Attenborough"
<(E-Mail Removed)> wrote:

>"Mike Treseler" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>> Note that if I ever had a
>> reason to select architectures,
>> the direct method shown above
>> is much simpler and easier to read
>> than the equivalent configuration.

>
>I'm in the process of switching from graphical design entry to text-only
>(which is what inspired me to write these Perl modules) and I'm feeling my
>way around the best way to use configurations.
>So far, I am using them for two things:
>1) Selecting between a fast RAM-block model which uses integer variables for
>data storage and a slow-but accurate FPGA vendor's model
>2) Switching the testbench's device-under-test between the RTL and the
>gate-level model.
>
>Configuration declarations don't seem to be serving me well for either
>case...
>1) Including all the hierarchy information to specify where the RAM blocks
>are instantiated is a real pain, what with having to include all the entity
>and instance names and generates.
>2) This seemed good, but I couldn't actually get it to work because the RTL
>had generics but the GLM did not. While a configuration declaration lets
>you change the generic and port mapping, it doesn't seem to let me specify
>"no generics" for an instantiation: "generic map ( )" is an error.
>
>And if I'm considering configuration specifications instead, which means I
>need to edit source recompile to change the architecture selection, it seems
>I might as well use direct instantiation.
>Using a preprocessor could be a nice way to control this (although it still
>needs a recompile): I could have a file which defines macros for the RAM
>architecture that I want, and include in any file where I instantiate a RAM
>block.
>
>in uart.vhd:
> #include "arch_config.vhdh"
> ...
> txfiforam : entity ram.dpram(RAM_ARCH) generic map (...
>
>in arch_config.vhdh:
> #define RAM_ARCH fast_int_model
>
>> Yes. Components are a big annoyance for me in dealing
>> with code by others. Why do double maintenance
>> on all the sub-entity port lists to maintain
>> default binding when no configurations or black-boxes are
>> used? Doooh!

>
><salesman_mode> If you were using my build system, you would just need to
>replace their component declaration for uart.switch_uart with "--<
>component uart.switch_uart >--", for example, and no further maintenance
>would be needed, or indeed any manual replacement of instantiations by
>direct instantiation. </salesman_mode>
>
>> > Cons:
>> > - You can't apply a configuration to this instantiation.

>>
>> This feature is rarely used for synthesis.
>> For testbenches, I prefer generic options.

>
>Do you mean you would put in an "if MY_GENERIC=1 generate..." to select
>between architectures? That's an idea, for testbenches at least.


Yet another way is to leave out the architecture specification
altogether. VHDL will use whatever architecture has been most
recently compiled into the library.

So compile your RTL source then compile (*) and elaborate your
testbench. It will pick up the RTL version in the library.
Then compile your gate level source then compile and elaborate your
testbench. It will pick up the gate level version in the library.

Crude, but effective as long as you don't want to simulate your RTL
and gate level designs simultaneously.

(*) Note: strictly speaking you don't need to recompile your testbench
if only the dut architecture is being recompiled. However, most of
the time the dut entity declaration will be compiled along with the
dut architecture (because they're in the same file) and the tools
require that the testbench be recompiled.

Regards,
Allan
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      03-01-2006
Allan Herriman wrote:

> So compile your RTL source then compile (*) and elaborate your
> testbench. It will pick up the RTL version in the library.
> Then compile your gate level source then compile and elaborate your
> testbench. It will pick up the gate level version in the library.
> Crude, but effective as long as you don't want to simulate your RTL
> and gate level designs simultaneously.


After writing a generic rtl/gate testbench example, I must agree
that Allan's method is preferable.

The generic switch works ok, but it really makes
a mess of the testbench and causes annoying warnings about
the generated instances driving the same ports.
And flipping the switch requires either a command line
-G option or an edit of the constant assignment.

For me, a gate level sim is an exception rather than
the rule and it is not worth the impact to my standard
design flow to try and support it directly in the
testbench source. A little script using Allan's method
is probably the best way to go.

-- Mike Treseler
 
Reply With Quote
 
Michael Attenborough
Guest
Posts: n/a
 
      03-09-2006
"Mike Treseler" <(E-Mail Removed)> wrote in message
news:<(E-Mail Removed)>...
> Michael Attenborough wrote:
> >
> > I'm in the process of switching from graphical design entry to text-only
> > (which is what inspired me to write these Perl modules) and I'm feeling

my
> > way around the best way to use configurations.
> > So far, I am using them for two things:
> > 1) Selecting between a fast RAM-block model which uses integer variables

for
> > data storage and a slow-but accurate FPGA vendor's model
> > 2) Switching the testbench's device-under-test between the RTL and the
> > gate-level model.

>
> I expect that either of these could be handled
> using a boolean generic selecting
> one of two direct instances in the testbench.
> Something like
> IF fast_c generate ...
> IF not fast_c generate ...


In the case of the RAM model selection, this means changing all the entities
in the instantiation path so that I can thread a 'generic' value through to
them - yuck. Possibly an feasible option for the device-under-test
selection, though - although here, the configuration is fairly simple to
write, and arguably neater.

> > While a configuration declaration lets
> > you change the generic and port mapping, it doesn't seem to let me

specify
> > "no generics" for an instantiation: "generic map ( )" is an error.

>
> You could assign generic defaults for this
> case and and just leave out the map.


That doesn't work, because the default generics (from the RTL entity) are
not what I want: I want no generics when I am plugging in the gatelevel
model in place of the RTL. ModelSim gives me an error "Entity does not have
a generic named xxx" when I try to compile the configuration without a
generic map. I can define a completely different generic map if I want, but
I don't know how to specify an empty generic map. An omisssion from the
language spec?

> >>>Cons:
> >>>- You can't apply a configuration to this [direct] instantiation.


As far as I can see, I also can't apply a configuration to anything below a
directly instantiated entity/architecture in the instantiation tree - is
this true, or is it that I just don't know the correct syntax to do it?

Michael A


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Big projects divided into modules and sub-modules ImpalerCore C Programming 0 03-10-2011 03:01 PM
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
2 new comment-like characters in Python to aid development? dbhbarton@googlemail.com Python 29 03-11-2007 08:44 AM
[Meta] *Poll Results* Proposed new, moderated digital photography group (rec.photo.digital.moderated) Lionel Digital Photography 27 07-15-2004 11:24 AM



Advertisments