Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 153500

Article: 153500
Subject: Re: Internal BUS design: MUX or OR-GATE?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 15 Mar 2012 18:57:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
John Adair <g1@enterpoint.co.uk> wrote:

> Tristate muxes used to a good method in FPGAs prior to Spartan-3/3E/3A
> because the resource existed. The internal tristates don't exist in
> Spartan-3 and later so a synthesiser will attempt to convert to a
> logic function anyway. It might not always get that right as you
> physically can't do the tristate. Because of these uncertainies you
> might get a bigger, slower, mux this way.

It really doesn't make sense to generate an actual MUX, as that
would require a preceding priority encoder.

Two that are more obvious are AND/OR logic and OR/AND logic,
the former gives zero with no enables, the latter one.
(OR/AND uses active low enables. The synthsizer can always add
inverters where needed.)

Assuming the synthesizer knows about them, weak pull-ups should
generate the former, and weak pull-downs the latter.

If you do know that the synthesizer will generate one of those, does
it make more sense to rewrite the logic using one, or just leave it
as is?

-- glen


Article: 153501
Subject: Re: Free GUI top level integration tool for Verilog and VHDL
From: wzab <wzab01@gmail.com>
Date: Fri, 16 Mar 2012 02:24:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 12 Mar, 15:57, vtxsupp...@hotmail.com wrote:
> Hi,
> Pleased to introduce my new tool, VTM 2012. It is intended to be a
> table based edit tool for Verilog/VHDL module's interface definition,
> and unify the process of HDL coding and document writing. A demo is athttp://www.veriloghdl.org/demo.html
> These tools enable you to build the design's framework, both top down
> and bottom up styles. I want to design the HDL in even higher level. I
> would like to get some ideas on how people think it before VTM's
> completeness. I am now considering to add system verilog interface
> feature to it. But I see very few people using system verilog feature
> like interface in their RTL designs. Do you think it a valuable
> feature? Any comment is welcome.
> Thanks

How does it compare to the old good and free Perlilog (
http://www.billauer.co.il/perlilog.html )?
--
Regards,
WZab


Article: 153502
Subject: ways to find frequency of operation in early phase of the design
From: Vips <thevipulsinha@gmail.com>
Date: Fri, 16 Mar 2012 22:03:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello All ,

I am designing a module that has to run at 350MHz. I am in the
architecture phase and would like to know how to figure out the
possible frequency of operation of the design before entering the
synthesis phase. Normally we have to wait till the synthesis to get an
idea about the frequency of operation. I need a rough idea with 10-15%
error margin.

What if the frequecncy fails to meet the requrement and the difference
is very big and cannot be solved in the RTL optimization or syntheis
techniques. This amounts to again visiting the High level design to
figure out the bottlenecks .

I am interested in the techniques to find the rough idea of the
frequency of operation in the early phase of the design to meet the
frequency of demand if it is high speed design .

Secondly how to get a rough idea about the no of flops in the design
before entering the synthesis phase.

sharing any handout or methodology followed will be highly
appreciated.

THanks

Vips

Article: 153503
Subject: Re: ways to find frequency of operation in early phase of the design without syntheis
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 19 Mar 2012 09:41:49 +0000
Links: << >>  << T >>  << A >>
Vips <thevipulsinha@gmail.com> writes:

> Hello All ,
>
> I am designing a module that has to run at 350MHz. I am in the
> architecture phase and would like to know how to figure out the
> possible frequency of operation of the design before entering the
> synthesis phase. Normally we have to wait till the synthesis to get an
> idea about the frequency of operation. I need a rough idea with 10-15%
> error margin.

What FPGA family are you targetting?  Is your application amenable to
pipelining? Have you done anything similar before?  How much of it is
going to be dominated by the LUT timing, how much by the DSP/RAM blocks?

If you know what you are doing, and it's not too different a task to
previous ones, you might get within 15% without writing any code.  If
not, I'd be tempted to hire someone that does have that experience to do
you a design study.

>
> What if the frequecncy fails to meet the requrement and the difference
> is very big and cannot be solved in the RTL optimization or syntheis
> techniques. This amounts to again visiting the High level design to
> figure out the bottlenecks .

Yes, that's life.  Do the work up front if you already know enough, or
do enough work to learn enough.  Then you'll know.

>
> I am interested in the techniques to find the rough idea of the
> frequency of operation in the early phase of the design to meet the
> frequency of demand if it is high speed design .
>
> Secondly how to get a rough idea about the no of flops in the design
> before entering the synthesis phase.

Not usually an issue, unless (as someone else said recently) you're Ray
Andraka :) I always run out of LUTs first.  

Again estimations can be done by one skilled in the art, but the
accuracy depends on how well you understand what you are going to be
implementing.

>
> sharing any handout or methodology followed will be highly
> appreciated.

I think the best methodology (unless I'm seriously misreading your/you
employers existing capabilities) is to get some help in.  (And that's not a
pitch for work, I have plenty on already I'm afraid!)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 153504
Subject: Record type <-> std_logic_vector conversion - Python script
From: Wojciech M. Zabolotny <wzab@ise.pw.edu.pl>
Date: Mon, 19 Mar 2012 17:57:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
The record types in VHDL are very useful when designing more
complicated systems. However if you need to store data of record
types to memory or FIFO, it is necessary to convert such data 
to the std_logic_vector type.
Similarly, when such data are read from the memory or FIFO, 
it is necessary to convert to the original record type.
This problem was often discussed, eg. here:
http://stackoverflow.com/questions/3985694/serialize-vhdl-record
http://objectmix.com/vhdl/190447-converting-records-std_logic_vector.html

Finally I've decided to prepare a Python script which automatically
generates the appropriate VHDL package containing both the
records type declaration and functions to convert between this type and
std_logic_vector.

The input data is a "description file" containing:
1. The record type name in the first non-comment line:
   record name_of_my_type
2. A few (at least 1) field declarations, which may have two forms:
   name_of_the_field,type,number_of_bits
   or
   name_of_the_field,type,nr_of_left_bit,nr_of_right_bit

   the type may be either "signed" or "unsigned"
3. The end line, consisting of a single "end" word.

The description file may contain also multiple comment lines, containing
the hash "#" character in the first column.

For example if you run:
$ ./rec_to_pkg.py test1.rec

with the following test1.rec:

# This is a test record - packet descriptor
record pkt_desc
# Below are fields definitions
# First two pointers for linked list
# prv - previous
prv,unsigned,6
# nxt - next
nxt,unsigned,6
# Then address to the packet data
addr,unsigned,15,0
# Finally flags
flags,unsigned,9,2
end

You'll get the following VHDL package:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
package pkt_desc_pkg is

type pkt_desc is record
    prv : unsigned(5 downto 0);
    nxt : unsigned(5 downto 0);
    addr : unsigned(15 downto 0);
    flags : unsigned(9 downto 2);
end record;

constant pkt_desc_width : integer := 36;

function pkt_desc_to_stlv(
  constant din : pkt_desc)
  return std_logic_vector;

function stlv_to_pkt_desc(
  constant din : std_logic_vector)
  return pkt_desc;

end pkt_desc_pkg;

package body pkt_desc_pkg is

function pkt_desc_to_stlv(
  constant din : pkt_desc)
  return std_logic_vector is
  variable res : std_logic_vector(35 downto 0);
begin
  res(5 downto 0) := std_logic_vector(din.prv);
  res(11 downto 6) := std_logic_vector(din.nxt);
  res(27 downto 12) := std_logic_vector(din.addr);
  res(35 downto 28) := std_logic_vector(din.flags);
  return res;
end pkt_desc_to_stlv;

function stlv_to_pkt_desc(
  constant din : std_logic_vector)
  return pkt_desc is
  variable res : pkt_desc;
begin
  res.prv:=unsigned(din(5 downto 0));
  res.nxt:=unsigned(din(11 downto 6));
  res.addr:=unsigned(din(27 downto 12));
  res.flags:=unsigned(din(35 downto 28));
  return res;
end stlv_to_pkt_desc;

end pkt_desc_pkg;

Such automatic handling of the record type declaration and of conversion
functions should minimize nember of errors due to mistakes in mapping
of record's fields into the bits of the std_logic_vector.

Please note, that the information about the total number of bits in our
record type is generated as name_of_my_type_width 
(pkt_desc_width in the above example).

I hope, that you'll find this script useful.
As it is published as PUBLIC DOMAIN, you are free to modify and use it
in any way you want.

Wojciech M. Zabolotny
wzab@ise.pw.edu.pl

Article: 153505
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: Wojciech M. Zabolotny <wzab@ise.pw.edu.pl>
Date: Mon, 19 Mar 2012 18:07:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
In the previous message I'have forgotten to provide link to the announced
script.
It has been published in "alt.sources" Usenet group.
See
http://groups.google.com/group/alt.sources/browse_frm/thread/53ea61208013e9d1
Or look for topic "Script to generate VHDL package for conversion between the
record type and std_logic_vector"
If you want to unpack the archive from the Google archive, remember to
select "show original" option. Otherwise the indendation of the Python 
source will be damaged.
-- 
Regards,
WZab

Article: 153506
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 19 Mar 2012 18:37:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wrote:
> The record types in VHDL are very useful when designing more
> complicated systems. However if you need to store data of record
> types to memory or FIFO, it is necessary to convert such data=20
> to the std_logic_vector type.
> Similarly, when such data are read from the memory or FIFO,=20
> it is necessary to convert to the original record type.
> This problem was often discussed, eg. here:
> http://stackoverflow.com/questions/3985694/serialize-vhdl-record
> http://objectmix.com/vhdl/190447-converting-records-std_logic_vector.html
>=20

Note that the 'objectmix.com' link that you reference also presents a solut=
ion that does not require any other language.

Kevin Jennings

Additional links for more information:
https://www.google.com/webhp?sourceid=3Dnavclient&ie=3DUTF-8#hl=3Den&sclien=
t=3Dpsy-ab&q=3Dto_std_logic_vector+from_std_logic_vector+kevin+jennings&oq=
=3Dto_std_logic_vector+from_std_logic_vector+kevin+jennings&aq=3Df&aqi=3D&a=
ql=3D1&gs_sm=3D3&gs_upl=3D3469l3469l1l3984l2l2l0l0l0l0l156l296l0.2l2l0&gs_l=
=3Dhp.3...3469l3469l1l3984l2l2l0l0l0l0l156l296l0j2l2l0.cqn.1.&pbx=3D1&bav=
=3Don.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=3D2f01f92557ed5155&biw=3D1290&bih=3D88=
7

Article: 153507
Subject: Re: Internal BUS design: MUX or OR-GATE?
From: Haiwen <heavenfish@gmail.com>
Date: Mon, 19 Mar 2012 21:45:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 16, 2:57=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> John Adair <g...@enterpoint.co.uk> wrote:
> > Tristate muxes used to a good method in FPGAs prior to Spartan-3/3E/3A
> > because the resource existed. The internal tristates don't exist in
> > Spartan-3 and later so a synthesiser will attempt to convert to a
> > logic function anyway. It might not always get that right as you
> > physically can't do the tristate. Because of these uncertainies you
> > might get a bigger, slower, mux this way.
>
> It really doesn't make sense to generate an actual MUX, as that
> would require a preceding priority encoder.
>
> Two that are more obvious are AND/OR logic and OR/AND logic,
> the former gives zero with no enables, the latter one.
> (OR/AND uses active low enables. The synthsizer can always add
> inverters where needed.)
>
> Assuming the synthesizer knows about them, weak pull-ups should
> generate the former, and weak pull-downs the latter.
>
> If you do know that the synthesizer will generate one of those, does
> it make more sense to rewrite the logic using one, or just leave it
> as is?
>
> -- glen

I actually is using weak pull-down for my test bench to get right RTL
simulation results. I'm not aware that this can also direct
Synthesizer's results, I thought the weak pull-down buffers are not
recognized by Synthesizers. I'll give it a try to see whether it
works, then I don't need to convert all the tri-state buffers to OR-
GATE manually.

Thanks for the information

Best Regards,
Haiwen

Article: 153508
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: wzab <wzab01@gmail.com>
Date: Tue, 20 Mar 2012 00:34:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Mar, 02:37, KJ <kkjenni...@sbcglobal.net> wrote:
> On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wrote:
> > The record types in VHDL are very useful when designing more
> > complicated systems. However if you need to store data of record
> > types to memory or FIFO, it is necessary to convert such data
> > to the std_logic_vector type.
> > Similarly, when such data are read from the memory or FIFO,
> > it is necessary to convert to the original record type.
> > This problem was often discussed, eg. here:
> >http://stackoverflow.com/questions/3985694/serialize-vhdl-record
> >http://objectmix.com/vhdl/190447-converting-records-std_logic_vector....
>
> Note that the 'objectmix.com' link that you reference also presents a solution that does not require any other language.
>
> Kevin Jennings
>
> Additional links for more information:https://www.google.com/webhp?sourceid=navclient&ie=UTF-8#hl=en&sclien...

Yes, I know, but it seems to me, that it requires manual allocation of
bit ranges in the std_logic_vector so that
record fields do not overlap. If the width of any field is changed,
this allocation must be recalculated, which may lead
to errors. Have I missed something?

Wojtek Zabolotny


Article: 153509
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Tue, 20 Mar 2012 09:16:07 +0100
Links: << >>  << T >>  << A >>
"Wojciech M. Zabolotny" <wzab@ise.pw.edu.pl> wrote in message 
news:slrnjmessg.64b.wzab@wzab.nasz.dom...
> The record types in VHDL are very useful when designing more
> complicated systems. However if you need to store data of record
> types to memory or FIFO, it is necessary to convert such data
> to the std_logic_vector type.

Altera's Quartus2 (10.x+) seems to be able to instanciate arrays of records 
as memory in basic cases. You may have a problem if you index the different 
items in the record with different indexes and/or from clock domains, so 
better be careful. I assume this will be resolved in a future version.



Article: 153510
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: wzab <wzab01@gmail.com>
Date: Tue, 20 Mar 2012 02:13:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Mar, 09:16, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote:
> "Wojciech M. Zabolotny" <w...@ise.pw.edu.pl> wrote in messagenews:slrnjmessg.64b.wzab@wzab.nasz.dom...
>
> > The record types in VHDL are very useful when designing more
> > complicated systems. However if you need to store data of record
> > types to memory or FIFO, it is necessary to convert such data
> > to the std_logic_vector type.
>
> Altera's Quartus2 (10.x+) seems to be able to instanciate arrays of records
> as memory in basic cases. You may have a problem if you index the different
> items in the record with different indexes and/or from clock domains, so
> better be careful. I assume this will be resolved in a future version.

Yes, for inferred FIFOs and RAMs it worked both in Quartus and ISE for
quite
a long time (I don't remember in which version I've used it
successfully
for the first time).

However the problem is if you need to use e.g. more complicated FIFO
generated
by the CORE Generator, which has input and output of std_logic_vector
type.

Article: 153511
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Tue, 20 Mar 2012 10:58:07 +0100
Links: << >>  << T >>  << A >>
"wzab" <wzab01@gmail.com> wrote in message 
news:c160299b-a585-428a-9b73-938e041854c8@9g2000vbq.googlegroups.com...
> On 20 Mar, 09:16, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote:
>> "Wojciech M. Zabolotny" <w...@ise.pw.edu.pl> wrote in 
>> messagenews:slrnjmessg.64b.wzab@wzab.nasz.dom...
>>
>> > The record types in VHDL are very useful when designing more
>> > complicated systems. However if you need to store data of record
>> > types to memory or FIFO, it is necessary to convert such data
>> > to the std_logic_vector type.
>>
>> Altera's Quartus2 (10.x+) seems to be able to instanciate arrays of 
>> records
>> as memory in basic cases. You may have a problem if you index the 
>> different
>> items in the record with different indexes and/or from clock domains, so
>> better be careful. I assume this will be resolved in a future version.
>
> Yes, for inferred FIFOs and RAMs it worked both in Quartus and ISE for
> quite
> a long time (I don't remember in which version I've used it
> successfully
> for the first time).
>
> However the problem is if you need to use e.g. more complicated FIFO
> generated
> by the CORE Generator, which has input and output of std_logic_vector
> type.

I try to stay away from coregen functions as much as I can to make portable 
code. Unfortunately I'm very often forced to :(
But inferring RAM has never bee the problem really. I know some oldtimers 
that are afraid to, maybe because of the history of old implementation 
tools, but I've become very confident with it.
If I get problems with a long record with multiple domains together with 
dual port and different access widths on in/out, I prefer splitting the 
record into many subrecords or subvectors to make it easier for the tool.



Article: 153512
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 20 Mar 2012 04:31:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, March 20, 2012 3:34:50 AM UTC-4, wzab wrote:
> On 20 Mar, 02:37, KJ <kkjenni...@sbcglobal.net> wrote:
> > On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wrote=
:
> > > The record types in VHDL are very useful when designing more
> > > complicated systems. However if you need to store data of record
> > > types to memory or FIFO, it is necessary to convert such data
> > > to the std_logic_vector type.
> > > Similarly, when such data are read from the memory or FIFO,
> > > it is necessary to convert to the original record type.
> > > This problem was often discussed, eg. here:
> > >http://stackoverflow.com/questions/3985694/serialize-vhdl-record
> > >http://objectmix.com/vhdl/190447-converting-records-std_logic_vector..=
..
> >
> > Note that the 'objectmix.com' link that you reference also presents a s=
olution that does not require any other language.
> >
> > Kevin Jennings
> >
> > Additional links for more information:https://www.google.com/webhp?sour=
ceid=3Dnavclient&ie=3DUTF-8#hl=3Den&sclien...
>=20
> Yes, I know, but it seems to me, that it requires manual allocation of
> bit ranges in the std_logic_vector so that
> record fields do not overlap. If the width of any field is changed,
> this allocation must be recalculated, which may lead
> to errors. Have I missed something?
>=20

Yes, the record type must be updated (and that's the only thing) with the c=
orrect bit field positions but this is not really much of a problem for the=
 following reasons:
- One of the primary usages is to map bit fields for a software interface. =
 Interfaces have specifications that must be adhered to so the typing in of=
 the bit positions is really just implementation of that part of the specif=
ication.  Yes, I also know that some like to generate documentation (aka sp=
ecification) from the code, but I've yet to meet the software person who is=
 happy to have a fluid interface.  The software design will have a similar =
typed in bit position interface definition defined in some header file in t=
he language of their choice.  Having the hardware design magically change b=
it field positions allows the hardware designer to be lazy by not forcing a=
 specification update or even notification to others that are affected...no=
w if you're a one man show doing hardware and software, maybe that's OK, bu=
t if that should ever change...well...
- The record type definition has the bit field positions all right there, a=
nd can be visually inspected pretty easily...subject to error I agree.
- When you make a change, you do check that it's working in simulation, cor=
rect?

Not saying the Python script isn't useful.  The tradeoff has to do with add=
ing another tool into the design flow that needs to be managed and understo=
od by everyone who will use and support the tool over the entire lifetime o=
f the design.

Kevin Jennings

Article: 153513
Subject: Re: ways to find frequency of operation in early phase of the design without syntheis
From: "SCOTTY9000" <scotty9000@n_o_s_p_a_m.gmail.com>
Date: Tue, 20 Mar 2012 06:55:40 -0500
Links: << >>  << T >>  << A >>
The xilinx documentation has got helpful tables in giving information about
fmax for various structures such as BRAM, CAM etc.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153514
Subject: Re: Record type <-> std_logic_vector conversion - Python script
From: wzab <wzab01@gmail.com>
Date: Tue, 20 Mar 2012 06:18:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Mar, 12:31, KJ <kkjenni...@sbcglobal.net> wrote:
> On Tuesday, March 20, 2012 3:34:50 AM UTC-4, wzab wrote:
> > On 20 Mar, 02:37, KJ <kkjenni...@sbcglobal.net> wrote:
> > > On Monday, March 19, 2012 1:57:36 PM UTC-4, Wojciech M. Zabolotny wro=
te:
> > > > The record types in VHDL are very useful when designing more
> > > > complicated systems. However if you need to store data of record
> > > > types to memory or FIFO, it is necessary to convert such data
> > > > to the std_logic_vector type.
> > > > Similarly, when such data are read from the memory or FIFO,
> > > > it is necessary to convert to the original record type.
> > > > This problem was often discussed, eg. here:
> > > >http://stackoverflow.com/questions/3985694/serialize-vhdl-record
> > > >http://objectmix.com/vhdl/190447-converting-records-std_logic_vector=
....
>
> > > Note that the 'objectmix.com' link that you reference also presents a=
 solution that does not require any other language.
>
> > > Kevin Jennings
>
> > > Additional links for more information:https://www.google.com/webhp?so=
urceid=3Dnavclient&ie=3DUTF-8#hl=3Den&sclien...
>
> > Yes, I know, but it seems to me, that it requires manual allocation of
> > bit ranges in the std_logic_vector so that
> > record fields do not overlap. If the width of any field is changed,
> > this allocation must be recalculated, which may lead
> > to errors. Have I missed something?
>
> Yes, the record type must be updated (and that's the only thing) with the=
 correct bit field positions but this is not really much of a problem for t=
he following reasons:
> - One of the primary usages is to map bit fields for a software interface=
. =A0Interfaces have specifications that must be adhered to so the typing i=
n of the bit positions is really just implementation of that part of the sp=
ecification. =A0Yes, I also know that some like to generate documentation (=
aka specification) from the code, but I've yet to meet the software person =
who is happy to have a fluid interface. =A0The software design will have a =
similar typed in bit position interface definition defined in some header f=
ile in the language of their choice. =A0Having the hardware design magicall=
y change bit field positions allows the hardware designer to be lazy by not=
 forcing a specification update or even notification to others that are aff=
ected...now if you're a one man show doing hardware and software, maybe tha=
t's OK, but if that should ever change...well...
> - The record type definition has the bit field positions all right there,=
 and can be visually inspected pretty easily...subject to error I agree.
> - When you make a change, you do check that it's working in simulation, c=
orrect?
>
> Not saying the Python script isn't useful. =A0The tradeoff has to do with=
 adding another tool into the design flow that needs to be managed and unde=
rstood by everyone who will use and support the tool over the entire lifeti=
me of the design.
>
> Kevin Jennings

Yes, you are definitely right. In case of building hardware/software
interface the allocation of bits for record fields should be known for
software.
However often i use such record<->std_logic_vector conversions
internally, inside of the chip, and then this problem does not exist.
If I have to connect the record type (after conversion) to the output
port, or to the software readable register, I use the similar script
to generate the C headers or C++ headers with this information to
assure both flexibility and maintainability.

My colleague has even built much more complicated tool for automatic
mapping of complex structures in FPGA into software readable objects:
http://tesla.desy.de/new_pages/TESLA_Reports/2005/pdf_files/tesla2005-22.pd=
f

Wojtek Zabolotny

Article: 153515
Subject: Re: Free GUI top level integration tool for Verilog and VHDL
From: vtxsupport@hotmail.com
Date: Tue, 20 Mar 2012 09:37:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi WZab,
I think all the tools for top level integration have the similar object and=
 outputs. The difference is how to use them.
VTC is very different from other tools.
A good and quick way to learn VTC is through a quick demo at http://www.ver=
iloghdl.org/demos/demo1.htm=20
Users' goal is to instantiate and connect modules. I saw many people dislik=
e such a job. I think through this job one can get a clear knowledge of the=
 whole project and a sense of achievement. VTC is very easy to learn. You c=
an even start to use it without learning. At the same time, many powerful f=
unction can guide user's operation.
One aim of VTC is to cost users' least operation. User can directly get the=
 correct result because no opportunity to make a mistake. Users need not to=
 learn additional complicated rules.
I hope this answers your question. For detailed comparisons, you can give a=
 sample and your current way. I will describe how VTC do it.

Thanks

Article: 153516
Subject: Re: ways to find frequency of operation in early phase of the
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 20 Mar 2012 11:48:14 -0500
Links: << >>  << T >>  << A >>
On Mon, 19 Mar 2012 09:41:49 +0000, Martin Thompson wrote:

> Vips <thevipulsinha@gmail.com> writes:
> 
>> Hello All ,
>>
>> I am designing a module that has to run at 350MHz. I am in the
>> architecture phase and would like to know how to figure out the
>> possible frequency of operation of the design before entering the
>> synthesis phase. Normally we have to wait till the synthesis to get an
>> idea about the frequency of operation. I need a rough idea with 10-15%
>> error margin.
> 
> What FPGA family are you targetting?  Is your application amenable to
> pipelining? Have you done anything similar before?  How much of it is
> going to be dominated by the LUT timing, how much by the DSP/RAM blocks?
> 
> If you know what you are doing, and it's not too different a task to
> previous ones, you might get within 15% without writing any code.  If
> not, I'd be tempted to hire someone that does have that experience to do
> you a design study.
> 
> 
>> What if the frequecncy fails to meet the requrement and the difference
>> is very big and cannot be solved in the RTL optimization or syntheis
>> techniques. This amounts to again visiting the High level design to
>> figure out the bottlenecks .
> 
> Yes, that's life.  Do the work up front if you already know enough, or
> do enough work to learn enough.  Then you'll know.
> 
> 
>> I am interested in the techniques to find the rough idea of the
>> frequency of operation in the early phase of the design to meet the
>> frequency of demand if it is high speed design .
>>
>> Secondly how to get a rough idea about the no of flops in the design
>> before entering the synthesis phase.
> 
> Not usually an issue, unless (as someone else said recently) you're Ray
> Andraka :) I always run out of LUTs first.
> 
> Again estimations can be done by one skilled in the art, but the
> accuracy depends on how well you understand what you are going to be
> implementing.
> 
> 
>> sharing any handout or methodology followed will be highly appreciated.
> 
> I think the best methodology (unless I'm seriously misreading your/you
> employers existing capabilities) is to get some help in.  (And that's
> not a pitch for work, I have plenty on already I'm afraid!)

You can also prototype the parts that you know, from experience, to be 
bottlenecks -- but without experience, you can't tell the bottlenecks.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 153517
Subject: Spartan 3 DiffPairs restricted to Banks 0 and 2?
From: Tobias Kahre <tobias.kahre@epb-dienstleistungen.de>
Date: Wed, 21 Mar 2012 15:58:48 +0100
Links: << >>  << T >>  << A >>
On a PCI Card I got a XC3SD1800A-4FGG676C.
While trying to establish a differential output pair on Pins K23,K22, i got the following message:

----------------------------------------------------------------------------
ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a
   single DIFFMTB component because the site type selected is not compatible.
   The root cause of failure is that the IOSTANDARD=LVDS_33 property is only
   supported in the TOP and BOTTOM IO banks.

   Further explanation:
   The component type is determined by the types of logic and the properties and
   configuration of the logic it contains. In this case an IO component of type
   DIFFMTB was chosen because the IO contains symbols and/or properties
   consistent with differential master usage and a IOSTANDARD=LVDS_33 property.
   Please double check that the types of logic elements and all of their
   relevant properties and configuration options are compatible with the
   physical site type of the constraint.
-----------------------------------------------------------------------------


The PCI Board Vendor claims in his manual, that these pins are suited for usage as a diff pair.
The Xilinx Datasheets do not say anything against this, IMHO.
The Xilinx mapping tool seems to have a different opinion:)

What am I doing wrong? Would a DIFFMLR be more suited for Banks 1 and 3? 


Lost Regards
Tobias


p.s:

from UCF File:
--------------
NET "dig_io[30]" IOSTANDARD = LVDS_33;
NET "dig_io[30]" LOC = K23;
NET "dig_io[31]" IOSTANDARD = LVDS_33;
NET "dig_io[31]" LOC = K22;


from top level file:
--------------------
buf_o_pxlclk: obufds port map (i => o_pxl_clk, o=> dig_io(30), ob => dig_io(31) );

Article: 153518
Subject: Re: Spartan 3 DiffPairs restricted to Banks 0 and 2?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 21 Mar 2012 08:46:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 21, 7:58=A0am, Tobias Kahre <tobias.ka...@epb-
dienstleistungen.de> wrote:
> On a PCI Card I got a XC3SD1800A-4FGG676C.
> While trying to establish a differential output pair on Pins K23,K22, i g=
ot the following message:
>
> -------------------------------------------------------------------------=
--=AD-
> ERROR:Pack:1107 - Pack was unable to combine the symbols listed below int=
o a
> =A0 =A0single DIFFMTB component because the site type selected is not com=
patible.
> =A0 =A0The root cause of failure is that the IOSTANDARD=3DLVDS_33 propert=
y is only
> =A0 =A0supported in the TOP and BOTTOM IO banks.
>
> =A0 =A0Further explanation:
> =A0 =A0The component type is determined by the types of logic and the pro=
perties and
> =A0 =A0configuration of the logic it contains. In this case an IO compone=
nt of type
> =A0 =A0DIFFMTB was chosen because the IO contains symbols and/or properti=
es
> =A0 =A0consistent with differential master usage and a IOSTANDARD=3DLVDS_=
33 property.
> =A0 =A0Please double check that the types of logic elements and all of th=
eir
> =A0 =A0relevant properties and configuration options are compatible with =
the
> =A0 =A0physical site type of the constraint.
> -------------------------------------------------------------------------=
--=AD--
>
> The PCI Board Vendor claims in his manual, that these pins are suited for=
 usage as a diff pair.
> The Xilinx Datasheets do not say anything against this, IMHO.
> The Xilinx mapping tool seems to have a different opinion:)
>
> What am I doing wrong? Would a DIFFMLR be more suited for Banks 1 and 3?
>
> Lost Regards
> Tobias
>
> p.s:
>
> from UCF File:
> --------------
> NET "dig_io[30]" IOSTANDARD =3D LVDS_33;
> NET "dig_io[30]" LOC =3D K23;
> NET "dig_io[31]" IOSTANDARD =3D LVDS_33;
> NET "dig_io[31]" LOC =3D K22;
>
> from top level file:
> --------------------
> buf_o_pxlclk: obufds port map (i =3D> o_pxl_clk, o=3D> dig_io(30), ob =3D=
> dig_io(31) );

The Spartan-3A DSP data sheet (DS610) includes the available pin
functionality for every pin.

Page 78
K23 - Bank 1 - IO_L46P_1
K22 - Bank 1 - IO_L46N_1

While both of these can be differential they are in Bank 1 which is a
side bank.

Table 12 has this footnote for the LVDS_33 and LVDS_25 IO standards
"These true differential output standards are supported only on FPGA
banks 0 and 2. Inputs are unrestricted. See the chapter "Using I/O
Resources" in UG331."

UG331, starting on page 358, describes the differential I/O support
and banking rules.  If the text is not clear then Table 10-20
explicitly documents that LVDS_25 and LVDS_33 outputs are only
available in Banks 0 and 2 (top and bottom).

The bottom line is that these two pins can be used for LVDS, but only
for a LVDS input.  Since you have assigned an output buffer to these
pins you are getting a DRC error.

Ed McGettigan
--
Xilinx Inc.

Article: 153519
Subject: Re: Spartan 3 DiffPairs restricted to Banks 0 and 2?
From: Tobias Kahre <tobias.kahre@epb-dienstleistungen.de>
Date: Thu, 22 Mar 2012 09:29:13 +0100
Links: << >>  << T >>  << A >>
On Wed, 21 Mar 2012 08:46:01 -0700 (PDT)
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

> On Mar 21, 7:58=A0am, Tobias Kahre <tobias.ka...@epb-
> dienstleistungen.de> wrote:
> > On a PCI Card I got a XC3SD1800A-4FGG676C.
> > While trying to establish a differential output pair on Pins K23,K22, i=
 got the following message:
> >
> > -----------------------------------------------------------------------=
----=AD-
> > ERROR:Pack:1107 - Pack was unable to combine the symbols listed below i=
nto a
> > =A0 =A0single DIFFMTB component because the site type selected is not c=
ompatible.
> > =A0 =A0The root cause of failure is that the IOSTANDARD=3DLVDS_33 prope=
rty is only
> > =A0 =A0supported in the TOP and BOTTOM IO banks.
> >
> > =A0 =A0Further explanation:
> > =A0 =A0The component type is determined by the types of logic and the p=
roperties and
> > =A0 =A0configuration of the logic it contains. In this case an IO compo=
nent of type
> > =A0 =A0DIFFMTB was chosen because the IO contains symbols and/or proper=
ties
> > =A0 =A0consistent with differential master usage and a IOSTANDARD=3DLVD=
S_33 property.
> > =A0 =A0Please double check that the types of logic elements and all of =
their
> > =A0 =A0relevant properties and configuration options are compatible wit=
h the
> > =A0 =A0physical site type of the constraint.
> > -----------------------------------------------------------------------=
----=AD--
> >
> > The PCI Board Vendor claims in his manual, that these pins are suited f=
or usage as a diff pair.
> > The Xilinx Datasheets do not say anything against this, IMHO.
> > The Xilinx mapping tool seems to have a different opinion:)
> >
> > What am I doing wrong? Would a DIFFMLR be more suited for Banks 1 and 3?
> >
> > Lost Regards
> > Tobias
> >
> > p.s:
> >
> > from UCF File:
> > --------------
> > NET "dig_io[30]" IOSTANDARD =3D LVDS_33;
> > NET "dig_io[30]" LOC =3D K23;
> > NET "dig_io[31]" IOSTANDARD =3D LVDS_33;
> > NET "dig_io[31]" LOC =3D K22;
> >
> > from top level file:
> > --------------------
> > buf_o_pxlclk: obufds port map (i =3D> o_pxl_clk, o=3D> dig_io(30), ob =
=3D> dig_io(31) );
>=20
> The Spartan-3A DSP data sheet (DS610) includes the available pin
> functionality for every pin.
>=20
> Page 78
> K23 - Bank 1 - IO_L46P_1
> K22 - Bank 1 - IO_L46N_1
>=20
> While both of these can be differential they are in Bank 1 which is a
> side bank.
>=20
> Table 12 has this footnote for the LVDS_33 and LVDS_25 IO standards
> "These true differential output standards are supported only on FPGA
> banks 0 and 2. Inputs are unrestricted. See the chapter "Using I/O
> Resources" in UG331."
>=20
> UG331, starting on page 358, describes the differential I/O support
> and banking rules.  If the text is not clear then Table 10-20
> explicitly documents that LVDS_25 and LVDS_33 outputs are only
> available in Banks 0 and 2 (top and bottom).
>=20
> The bottom line is that these two pins can be used for LVDS, but only
> for a LVDS input.  Since you have assigned an output buffer to these
> pins you are getting a DRC error.
>=20
> Ed McGettigan
> --
> Xilinx Inc.


Ed,

thank you for clarification. The documentation is really comprehensive, so =
sometimes it is difficult for me to catch up with every detail.
Since the hardware is finished, I will try to use DIFF_SSTL3 now.

Tobias

Article: 153520
Subject: Virtex6HXT PCIe 8X Gen2 timing closure problem
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 22 Mar 2012 23:00:41 GMT
Links: << >>  << T >>  << A >>
I'm having a terrible time getting the V6 PCIe core to consistently meet 
timing, it works occasionally but usually it misses. I've used the 
suggested constraints that Coregen puts out but that doesn't seem to be 
sufficient. There is a 500MHz section in the Xilinx core which is the 
source of the problems. Has anyone been able to get it to place and route 
reliably? Is there an area constraint for the 500MHz section or some 
specific flip flop placements that would help?

Article: 153521
Subject: Re: Virtex6HXT PCIe 8X Gen2 timing closure problem
From: "Like Learn" <like2learn@live.ca>
Date: Fri, 23 Mar 2012 10:55:48 -0600
Links: << >>  << T >>  << A >>
What makes you think the 500MHz section in the Xilinx core is the problem 
not else?

"General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message 
news:9t1p8pFcvgU1@mid.individual.net...
> I'm having a terrible time getting the V6 PCIe core to consistently meet
> timing, it works occasionally but usually it misses. I've used the
> suggested constraints that Coregen puts out but that doesn't seem to be
> sufficient. There is a 500MHz section in the Xilinx core which is the
> source of the problems. Has anyone been able to get it to place and route
> reliably? Is there an area constraint for the 500MHz section or some
> specific flip flop placements that would help? 


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Article: 153522
Subject: Spartan 3A counter speed ?
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 23 Mar 2012 14:13:25 -0500
Links: << >>  << T >>  << A >>
Hello,

Does anybody have a very rough estimate of how fast
you can run a 32-bit counter in a Spartan 3AN FPGA?

Thanks,

Jon

Article: 153523
Subject: Why are my S3A pins getting destroyed?
From: aleksazr@gmail.com
Date: Fri, 23 Mar 2012 12:56:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have a S350A VQFP100 on my custom board, with all
the pins connected to large pads all around the chip.

I have destroyed 3 pins, total.
Two pins can't be used as inputs anymore,
and the third lost tri-state ability.
BTW, the pins are in two VCC banks.

True, my soldering tip is not grounded,
but the last pin was destroyed a few days ago,
and I didn't physically touched the pad it is
connected to for at least 3 months.

First two pads I did touch a lot with my soldering tip
while testing, so I can believe that it was destroyed
by ESD. At that time, I have also soldering 10 other pads
near those two, but they didn't die.

But what about that third pin?
It is a part of the data bus (D2), located in top bank,
and it hasn't been touched by soldering tip or even the
scope for at least 3 months.

So, why did it die?


Article: 153524
Subject: Re: Why are my S3A pins getting destroyed?
From: aleksazr@gmail.com
Date: Fri, 23 Mar 2012 14:02:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
Damn it, I've found the error, the wire is badly soldered.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search