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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 150375

Article: 150375
Subject: Re: FPGA to PHY/MAC chip
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 13 Jan 2011 00:08:15 GMT
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

>On Jan 10, 1:32=A0pm, "buddylee9898"
><andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
>> > How much parsing will you need to do of the information from the
>> > PHY/MAC? =A0If you just need to do some setup, then read from one memor=
>y
>> > location over and over (which means that you'd be using low-level
>> > Ethernet in some exceedingly simple fashion) then -- maybe.
>>
>> Essentially, the whole idea of the port is to be sending a constant strea=
>m
>> of sensor data onto the network at about 8Mbps, and to receive commands t=
>o
>> change which sensor the data will be coming from, so the sending of data =
>is
>> fairly constant while the receiving is not.
>>
>> > You mentioned a "local network" above - you will need to support
>> > whatever protocol that network uses.
>>
>> Yes I will be using a local network which will contain a switch =A0and tw=
>o
>> computers which will have custom software which should not have to use IP
>> addressing, no? But I would like to get back to the point where d_s_klein
>> said yes there is a way to receive straight data. I have read the data
>> sheet for the ENC28J60, as well as data sheets for a few other chips I wa=
>s
>> considering, and in reading about them it seems fairly straightforward in
>> that you are simply writing data to the chip (write command plus the pack=
>et
>> data addresses, etc) and reading in a very similar way. Now I have tried =
>to
>> implement a state machine in order to have this working but without luck =
>so
>> far. Is this a silly way to try this where there is no way to avoid using
>> the picoblaze, or is this feasible to some degree? =A0 =A0 =A0 =A0
>>
>> --------------------------------------- =A0 =A0 =A0 =A0
>> Posted throughhttp://www.FPGARelated.com
>
>I can't say much about sending data over Ethernet, but be aware that
>the Picoblaze is a VERY minimal processor with a very minimal address
>space and program size.  If you end up going that route, will it be

That depends on the type of FPGA. If you have large blockrams you can
write a decent piece of code. Altough the instruction set is small, it
is quite effective. If you create some hardware accellerators for
common tasks like calculating the CRC, multiplying, etc it can be
extremely powerful!

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 150376
Subject: Re: FPGA to PHY/MAC chip
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 Jan 2011 05:12:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> rickman <gnu...@gmail.com> wrote:
> >On Jan 10, 1:32=3DA0pm, "buddylee9898"
> ><andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> >> > How much parsing will you need to do of the information from the
> >> > PHY/MAC? =3DA0If you just need to do some setup, then read from one =
memor=3D
> >y
> >> > location over and over (which means that you'd be using low-level
> >> > Ethernet in some exceedingly simple fashion) then -- maybe.
>
> >> Essentially, the whole idea of the port is to be sending a constant st=
rea=3D
> >m
> >> of sensor data onto the network at about 8Mbps, and to receive command=
s t=3D
> >o
> >> change which sensor the data will be coming from, so the sending of da=
ta =3D
> >is
> >> fairly constant while the receiving is not.
>
> >> > You mentioned a "local network" above - you will need to support
> >> > whatever protocol that network uses.
>
> >> Yes I will be using a local network which will contain a switch =3DA0a=
nd tw=3D
> >o
> >> computers which will have custom software which should not have to use=
 IP
> >> addressing, no? But I would like to get back to the point where d_s_kl=
ein
> >> said yes there is a way to receive straight data. I have read the data
> >> sheet for the ENC28J60, as well as data sheets for a few other chips I=
 wa=3D
> >s
> >> considering, and in reading about them it seems fairly straightforward=
 in
> >> that you are simply writing data to the chip (write command plus the p=
ack=3D
> >et
> >> data addresses, etc) and reading in a very similar way. Now I have tri=
ed =3D
> >to
> >> implement a state machine in order to have this working but without lu=
ck =3D
> >so
> >> far. Is this a silly way to try this where there is no way to avoid us=
ing
> >> the picoblaze, or is this feasible to some degree? =3DA0 =3DA0 =3DA0 =
=3DA0
>
> >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0
> >> Posted throughhttp://www.FPGARelated.com
>
> >I can't say much about sending data over Ethernet, but be aware that
> >the Picoblaze is a VERY minimal processor with a very minimal address
> >space and program size. =A0If you end up going that route, will it be
>
> That depends on the type of FPGA. If you have large blockrams you can
> write a decent piece of code. Altough the instruction set is small, it
> is quite effective. If you create some hardware accellerators for
> common tasks like calculating the CRC, multiplying, etc it can be
> extremely powerful!

Unless it has been updated since I looked at it, the constraint on
memory size was not the FPGA, but the architecture itself.  The PC is
only 12 bits or so.  Admittedly, 4K is a decent hunk of assembly code
to write by hand, but the question is how much code does it take to
implement IP, etc.

Rick

Article: 150377
Subject: script for chipscope cores
From: alex <user@compgroups.net/>
Date: Thu, 13 Jan 2011 08:14:33 -0600
Links: << >>  << T >>  << A >>
Hi there,
I would like to have access to my chipscope cores via script, in order to have unattended automatic measurements (ila) and parameter variations (vio). for the vio cores chipscope analyzer offers an API with tcl access. ILA is not supported yet, but, according to xilinx, will be supported in ISE 14.1. TCL scripts for JTAG access are available but this is really "lowlevel" and unhandy. 
I wonder if nobody else has this problem. 
The best would be to have direct access to the cores via jtag with a high-level scripting language like python.
is there any solution?



Article: 150378
Subject: Re: FPGA to PHY/MAC chip
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 13 Jan 2011 06:58:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 13, 7:12=A0am, rickman <gnu...@gmail.com> wrote:
> On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>
>
>
> > rickman <gnu...@gmail.com> wrote:

<snip>

>
> > >I can't say much about sending data over Ethernet, but be aware that
> > >the Picoblaze is a VERY minimal processor with a very minimal address
> > >space and program size. =A0If you end up going that route, will it be
>
> > That depends on the type of FPGA. If you have large blockrams you can
> > write a decent piece of code. Altough the instruction set is small, it
> > is quite effective. If you create some hardware accellerators for
> > common tasks like calculating the CRC, multiplying, etc it can be
> > extremely powerful!
>
> Unless it has been updated since I looked at it, the constraint on
> memory size was not the FPGA, but the architecture itself. =A0The PC is
> only 12 bits or so. =A0Admittedly, 4K is a decent hunk of assembly code
> to write by hand, but the question is how much code does it take to
> implement IP, etc.
>
> Rick

The amount of memory available for the PicoBlaze depends on which
version you are using. There are multiple versions targeted at the
different Spartan and Virtex generations.

I took at some of my code for a PicoBlaze that is part of an offload
engine for receiving a custom protocol wrapped in UDP/IP.  It was
about 1000 lines, about 350 of that was constants and comments. There
was minor hardware support to put the headers where the PicoBlaze
could read them, in addition to sending the entire packet to a FIFO.
A fair amount of the code was for setting up DMA engines, and other
stuff.

As long as you don't support reassembling fragmented IP packets, or
the IP options field, the entire Ethernet/IP/UDP stack is very simple
to deal with, and well within reach of a PicoBlaze or a state machine.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 150379
Subject: Re: FPGA to PHY/MAC chip
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 13 Jan 2011 18:44:08 GMT
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

>On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>> rickman <gnu...@gmail.com> wrote:
>> >On Jan 10, 1:32=3DA0pm, "buddylee9898"
>> ><andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
>> >> > How much parsing will you need to do of the information from the
>> >> > PHY/MAC? =3DA0If you just need to do some setup, then read from one =
>memor=3D
>> >y
>> >> > location over and over (which means that you'd be using low-level
>> >> > Ethernet in some exceedingly simple fashion) then -- maybe.
>>
>> >> Essentially, the whole idea of the port is to be sending a constant st=
>rea=3D
>> >m
>> >> of sensor data onto the network at about 8Mbps, and to receive command=
>s t=3D
>> >o
>> >> change which sensor the data will be coming from, so the sending of da=
>ta =3D
>> >is
>> >> fairly constant while the receiving is not.
>>
>> >> > You mentioned a "local network" above - you will need to support
>> >> > whatever protocol that network uses.
>>
>> >> Yes I will be using a local network which will contain a switch =3DA0a=
>nd tw=3D
>> >o
>> >> computers which will have custom software which should not have to use=
> IP
>> >> addressing, no? But I would like to get back to the point where d_s_kl=
>ein
>> >> said yes there is a way to receive straight data. I have read the data
>> >> sheet for the ENC28J60, as well as data sheets for a few other chips I=
> wa=3D
>> >s
>> >> considering, and in reading about them it seems fairly straightforward=
> in
>> >> that you are simply writing data to the chip (write command plus the p=
>ack=3D
>> >et
>> >> data addresses, etc) and reading in a very similar way. Now I have tri=
>ed =3D
>> >to
>> >> implement a state machine in order to have this working but without lu=
>ck =3D
>> >so
>> >> far. Is this a silly way to try this where there is no way to avoid us=
>ing
>> >> the picoblaze, or is this feasible to some degree? =3DA0 =3DA0 =3DA0 =
>=3DA0
>>
>> >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0
>> >> Posted throughhttp://www.FPGARelated.com
>>
>> >I can't say much about sending data over Ethernet, but be aware that
>> >the Picoblaze is a VERY minimal processor with a very minimal address
>> >space and program size. =A0If you end up going that route, will it be
>>
>> That depends on the type of FPGA. If you have large blockrams you can
>> write a decent piece of code. Altough the instruction set is small, it
>> is quite effective. If you create some hardware accellerators for
>> common tasks like calculating the CRC, multiplying, etc it can be
>> extremely powerful!
>
>Unless it has been updated since I looked at it, the constraint on
>memory size was not the FPGA, but the architecture itself.  The PC is
>only 12 bits or so.  Admittedly, 4K is a decent hunk of assembly code
>to write by hand, but the question is how much code does it take to
>implement IP, etc.

If you stay away from tcp/ip it is very feasible to implement the UDP
and ARP parts of the IP protocol.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 150380
Subject: Verilog Book for VHDL Users
From: rickman <gnuarm@gmail.com>
Date: Fri, 14 Jan 2011 08:44:28 -0800 (PST)
Links: << >>  << T >>  << A >>
I am finally going to learn Verilog for real after using VHDL for 15
years.  I've done a little work with Verilog and found it relatively
easy to use.  Now I want to learn the details and especially how not
to make mistakes.

VHDL has the problem of not letting you do things unless you make it
explicitly clear what you want to do.  My understanding is that
Verilog will let you not specify fully what you want without
complaining, but you have to know what the default behavior will be in
those situations or it may not happen the way you expect.  This is
what I need detailed info on.

Otherwise I am looking for something that covers synthesis well and
include info on writing test benches.

I have "HDL Chip Design" by Douglas Smith, third printing 1997.  This
book covers both VHDL and Verilog, side by side, but has an odd style
and often does not cover all the details of a topic clearly.  There
are times I can only find the info I want if I analyze the example
code very, very carefully.

Searching here I found recommendations for "The Verilog=AE Hardware
Description Language", Donald E. Thomas and "HDL Programming
Fundamentals: VHDL and Verilog", Nazeih Botros.  The former appears to
be a bit long in the tooth and the latest edition (which is the only
one covering the 2001 revision of the standard) is quite pricey.  The
latter is another dual book comparing VHDL and Verilog side by side.
I don't know about its organization.

What do the Verilog users recommend in my case?  Why do you like the
books you like?

Rick

Article: 150381
Subject: Re: Verilog Book for VHDL Users
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Fri, 14 Jan 2011 18:19:43 +0000
Links: << >>  << T >>  << A >>
On Fri, 14 Jan 2011 08:44:28 -0800 (PST), rickman wrote:

> What do the Verilog users recommend in my case? 
> Why do you like the books you like?

Rick,

I've always found that Verilog is nowhere near so well
served by textbooks as VHDL.  I can speculate why that 
is, but I don't know for sure.  I haven't met ANY book 
on Verilog for design that I really like.

Since you've been doing this for a loooong time and 
you know exactly what to expect from HDL synthesis, 
you may find it better to pick up the basics by osmosis
(you probably did that already) and then go for a more
advanced tips-and-tricks book like Stu Sutherland and
Don Mills's Verilog and SystemVerilog Gotchas.

For testbenches, it's hard to beat the second edition
of Janick Bergeron's Writing Testbenches.  That one 
covers both VHDL and Verilog, but it's a goldmine of
good sense and useful ideas.  There's also an "edition
2.5" called Writing Testbenches in SystemVerilog, or
something like that; it's OK but you probably want to
get a good feel for more traditional testbench writing
styles before you attack SystemVerilog's bottomless pit.
There are interesting things you can do with Verilog
testbenches that you simply can't begin to do in VHDL,
so you'll probably want to mess around with some of
Janick's examples and see what parts of it can be made
to work for you.

There are good resources on Cliff Cummings' website
www.sunburst-design.com although, as reported here on
many occasions, I profoundly disagree with some of 
Cliff's conclusions about good style.  Again, you're
plenty experienced enough to make up your own mind
about such things.

Finally, you'll also encounter things that you have
been able to do easily in VHDL but are devil-hard
or just plain impossible in Verilog, especially 
when it comes to designing parameterizable blocks.
And you'll have to decide just how to soothe your
conscience after you start using the Verilog 
macro preprocessor.

And another thing... In VHDL you got frustrated with
the clunky syntax and restrictive rules for doing
arithmetic on vectors, right?  And it'll all be so
much easier in Verilog, with hardly any red tape.
But you forget at your peril the arcane and complex
rules about arithmetic bit-width in Verilog.  Trawling
back through the comp.lang.verilog archives in search
of wisdom from Steven Sharp will save you much pain.

Good luck
-- 
Jonathan Bromley

Article: 150382
Subject: Re: Verilog Book for VHDL Users
From: Gabor <gabor@alacron.com>
Date: Fri, 14 Jan 2011 10:46:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 14, 11:44=A0am, rickman <gnu...@gmail.com> wrote:
> I am finally going to learn Verilog for real after using VHDL for 15
> years. =A0I've done a little work with Verilog and found it relatively
> easy to use. =A0Now I want to learn the details and especially how not
> to make mistakes.
>
> VHDL has the problem of not letting you do things unless you make it
> explicitly clear what you want to do. =A0My understanding is that
> Verilog will let you not specify fully what you want without
> complaining, but you have to know what the default behavior will be in
> those situations or it may not happen the way you expect. =A0This is
> what I need detailed info on.
>
> Otherwise I am looking for something that covers synthesis well and
> include info on writing test benches.
>
> I have "HDL Chip Design" by Douglas Smith, third printing 1997. =A0This
> book covers both VHDL and Verilog, side by side, but has an odd style
> and often does not cover all the details of a topic clearly. =A0There
> are times I can only find the info I want if I analyze the example
> code very, very carefully.
>
> Searching here I found recommendations for "The Verilog=AE Hardware
> Description Language", Donald E. Thomas and "HDL Programming
> Fundamentals: VHDL and Verilog", Nazeih Botros. =A0The former appears to
> be a bit long in the tooth and the latest edition (which is the only
> one covering the 2001 revision of the standard) is quite pricey. =A0The
> latter is another dual book comparing VHDL and Verilog side by side.
> I don't know about its organization.
>
> What do the Verilog users recommend in my case? =A0Why do you like the
> books you like?
>
> Rick

As Jonathan (a true HDL guru) pointed out it's not easy to find good
texts
on Verilog.  I started in by modifying and adding to existing projects
(our
company has adopted Verilog almost exclusively) and then went back
and read through Thomas & Moorby's book, an old text that predates
Verilog 2001.  While I don't think the book would have been a good
text
without the initial dabbling in Verilog, it definitely cleared up some
concepts
in my mind like blocking and non-blocking assignments and the syntax
of # delays.  Having already written in VHDL for some years you should
be able to pick this up quickly, since there are similar concepts in
VHDL (signals v. variables).  I also find it handy to have a good
language reference.
The official LRM is a bit dry and unfriendly, but makes the expected
workings clear (as mud).  However I generally refer to the Doulos
"Verilog Golden Reference Guide" when I need to look up some obscure
syntax that I don't use often, and sometimes just to browse through
and find constructs I've never come across before.  It is well
organized
and includes examples and "gotcha's" for most of the entries.

It would be nice if someone wrote a good book on synthesizable Verilog
with coding examples, but unfortunately that seems to be a moving
target
as many synthesis tools add more language coverage over time.  If
you're
designing with Xilinx, you can also glean some useful information from
the XST user's guide, which gives some templates for synthesizing into
FPGA features like memory and shift registers.

Good luck on your transformation,

Gabor

Article: 150383
Subject: Re: FPGA to PHY/MAC chip
From: rickman <gnuarm@gmail.com>
Date: Fri, 14 Jan 2011 11:51:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 13, 9:58=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Jan 13, 7:12=A0am, rickman <gnu...@gmail.com> wrote:
>
> > On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>
> > > rickman <gnu...@gmail.com> wrote:
>
> <snip>
>
>
>
>
>
> > > >I can't say much about sending data over Ethernet, but be aware that
> > > >the Picoblaze is a VERY minimal processor with a very minimal addres=
s
> > > >space and program size. =A0If you end up going that route, will it b=
e
>
> > > That depends on the type of FPGA. If you have large blockrams you can
> > > write a decent piece of code. Altough the instruction set is small, i=
t
> > > is quite effective. If you create some hardware accellerators for
> > > common tasks like calculating the CRC, multiplying, etc it can be
> > > extremely powerful!
>
> > Unless it has been updated since I looked at it, the constraint on
> > memory size was not the FPGA, but the architecture itself. =A0The PC is
> > only 12 bits or so. =A0Admittedly, 4K is a decent hunk of assembly code
> > to write by hand, but the question is how much code does it take to
> > implement IP, etc.
>
> > Rick
>
> The amount of memory available for the PicoBlaze depends on which
> version you are using. There are multiple versions targeted at the
> different Spartan and Virtex generations.

So what is the most memory available for the Picoblaze.  When I looked
at using the Picoblaze, one of the things I didn't like was that it
was all instantiated logic.  There were no parameters to tweek and any
changes to the architecture would require a new assembler.  That's why
I rolled my own.  It was a little bigger, but I thought it was much
better and ran fairly fast, over 50 MHz.  I don't recall how fast the
Picoblaze is.  I seem to recall that the instruction set is rather
stunted and the processor has relatively few registers.  But then I
haven't looked at it in years.  It would be nice if they had a short
document that explained the basic architectural features without a lot
of noise.

Rick

Article: 150384
Subject: Re: Verilog Book for VHDL Users
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Fri, 14 Jan 2011 13:56:00 -0600
Links: << >>  << T >>  << A >>
I dont think you should have much problem learning Verilog as I found it
easier than VHDL. I would read some of the articles at Sunburst design as
they explain some of the problems you might encounter like blocking vs non
blocking. I wouldnt bother buying any books as you can get most info off
the internet. 

Regards

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

Article: 150385
Subject: Re: Verilog Book for VHDL Users
From: "Bill Garber" <willy46pa@garberstreet.com>
Date: Fri, 14 Jan 2011 15:14:50 -0500
Links: << >>  << T >>  << A >>

"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote
in message news:TqednQam6MfNN63QnZ2dnUVZ_g-dnZ2d@giganews.com...
> I dont think you should have much problem learning Verilog as
> I found it easier than VHDL. I would read some of the articles
> at Sunburst design as they explain some of the problems you might
> encounter like blocking vs non-blocking. I wouldnt bother buying
> any books as you can get most info off the internet.  Regards
> Jon
> --------------------------------------- 
> Posted through http://www.FPGARelated.com

I agree with Jon, in that you have prior knowledge in the art,
but, if you are like me, learning from scratch for a particular
device, I bought this:

"FPGA PROTOTYPING BY VERILOG EXAMPLES"
     'XILINX SPARTAN™-3 VERSION'
             PONG P. CHU

It is very informative, and helps you build things properly.

I got mine through my sister, who works at Baker and Taylor.

Bill



Article: 150386
Subject: Re: Verilog Book for VHDL Users
From: "evilkidder@googlemail.com" <evilkidder@gmail.com>
Date: Fri, 14 Jan 2011 19:52:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 14, 4:44=A0pm, rickman <gnu...@gmail.com> wrote:
> I am finally going to learn Verilog for real after using VHDL for 15
> years. =A0I've done a little work with Verilog and found it relatively
> easy to use. =A0Now I want to learn the details and especially how not
> to make mistakes.
>
> VHDL has the problem of not letting you do things unless you make it
> explicitly clear what you want to do. =A0My understanding is that
> Verilog will let you not specify fully what you want without
> complaining, but you have to know what the default behavior will be in
> those situations or it may not happen the way you expect. =A0This is
> what I need detailed info on.
>

I also did a VHDL to Verilog transition a few years back.  The two key
points have been mentioned in this thread already - default arithmetic
rules and blocking/non-blocking.

The former is a bit of a pig.  The rules that deal with arithmetic
over different bit widths and signed/unsigned values are just a big
hack in my opinion (accumulated over 30 years).  I generally ignore
them and use explicit wire declarations when they are needed.  This is
a nice thing in Verilog - you don't need to declare a signal first and
then assign to it later on - you can make new 'wires' at any point in
your code.  Generally this means when I would need a conversion
function in VHDL to make my types or bit widths match I will introduce
a new 'wire'.  The rules become much simpler to comprehend because of
this.

The blocking/non-blocking thing simply requires restraint - there are
lots of coding styles that will work in Verilog.  That said it's
perfectly reasonable to use '<=3D' and '=3D' in a manner that matches
VHDL's '<=3D' and ':=3D' assignments.  The only difference is that in VHDL
signals and variables are distinct entities and therefore the compiler
can tell you when you have made a mistake.  Verilog can't, but its not
really that difficult to be a good citizen in this case.

I would also dispute the assertion that Verilog lack parameterization
capabilities.  At the module level Verilog is just as capable as
VHDL.  Functions and procedures are much more flexible in VHDL,
however.  On the other hand testbenches are dramatically easier in
Verilog.  For all it's many faults I prefer Verilog to VHDL because of
this.

Personally I think both languages are hugely flawed so I wrote my own.

-Andy


Article: 150387
Subject: Re: Verilog Book for VHDL Users
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Sat, 15 Jan 2011 10:38:03 +0000
Links: << >>  << T >>  << A >>
On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:

>The former is a bit of a pig.  The rules that deal with arithmetic
>over different bit widths and signed/unsigned values are just a big
>hack in my opinion (accumulated over 30 years).

I agree it's a pig - frighteningly easy to get wrong - but 
I'm not entirely sure its design is as bad as you imply.

There are many possible choices for how to deal with 
arbitrary-precision arithmetic, and I'm fairly certain 
that there is *no* choice that will give the intuitively
correct behaviour for everyone in every case.  Some of 
the options are:

- Permit unlimited bit growth of expressions so that the
  mathematical intent is preserved in all situations,
  narrowing only on final copy into a target object.
  This sounds nice, but doesn't sit nicely with the
  bounded sizes of physical hardware, so it may force
  you into generating a lot of explicit intermediate
  variables to model real hardware's behaviour 
  (although I sense that you may feel this to be
  a good thing rather than a disadvantage).

- Have every operation return a result whose bit width
  is determined solely by the operand widths and the 
  operation (VHDL).  This has the huge advantage of being
  relatively easy to define and understand, but leads to
  nonsenses in practice; either you get the carry-out from
  an add, in which case it's too wide to put back into 
  one of the operand variables, or you throw away the
  carry as numeric_std does.  Either way, some users will
  be forced into doing non-obvious things to get the
  results they want.

- Have context-determined size rules.  Verilog does this,
  and provides a fine example of how hard (impossible?) 
  it is to get all the rules right so that people don't 
  get nasty surprises.

It really isn't easy to make clear, reproducible rules
that do The Right Thing for everyone's needs.  I'm not
saying that either VHDL or Verilog have it exactly right,
but each has an internal consistency that's fairly
satisfying and comprehensible once you're used to it.

>  I generally ignore [the bit width rules]
>and use explicit wire declarations when they are needed.  This is
>a nice thing in Verilog - you don't need to declare a signal first and
>then assign to it later on - you can make new 'wires' at any point in
>your code.  Generally this means when I would need a conversion
>function in VHDL to make my types or bit widths match I will introduce
>a new 'wire'.  The rules become much simpler to comprehend because of
>this.

That's a useful idea, but it does push you into a style of
coding that's perhaps unnecessarily explicit and verbose.

[snip good sense about blocking/nonblocking]

>I would also dispute the assertion that Verilog lack parameterization
>capabilities.  At the module level Verilog is just as capable as
>VHDL.

I really don't think this is true, although V-2001 "generate"
plugs some of the most gaping holes.

Since 2005 Verilog has had a clear definition of "constant 
function".  Along with SystemVerilog's ability to give 
arbitrary data types to parameters, this makes things much
better because you can now compute parameter values in a
reasonably complicated way if you wish - just as you've been
able to do in VHDL since forever.  It's too little too late,
though, and it's still at the mercy of tool support in 
synthesis.  And, as you also point out, the power of VHDL's
unconstrained subprogram arguments has no match in Verilog;
that has an impact on design parameterization too.

>testbenches are dramatically easier in Verilog.

It's hard to disagree with this.

>Personally I think both languages are hugely flawed so I wrote my own.

What specific flaws have you overcome, and what new ones have
you introduced? :-)
-- 
Jonathan Bromley

Article: 150388
Subject: Re: Verilog Book for VHDL Users
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sat, 15 Jan 2011 11:55:07 +0100
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:
> 
>> The former is a bit of a pig.  The rules that deal with arithmetic
>> over different bit widths and signed/unsigned values are just a big
>> hack in my opinion (accumulated over 30 years).
> 
> I agree it's a pig - frighteningly easy to get wrong - but 
> I'm not entirely sure its design is as bad as you imply.
> 
> There are many possible choices for how to deal with 
> arbitrary-precision arithmetic, and I'm fairly certain 
> that there is *no* choice that will give the intuitively
> correct behaviour for everyone in every case.  Some of 
> the options are:
> 
> - Permit unlimited bit growth of expressions so that the
>   mathematical intent is preserved in all situations,

That's what MyHDL does, and I believe it is the intuitively
correct behavior for arithmetic.

>   narrowing only on final copy into a target object.

MyHDL doesn't do this: it checks whether the value is
within the stated target bounds and gives you a run-time
error when it's not. It never throws anything away
silently.

>   This sounds nice, but doesn't sit nicely with the
>   bounded sizes of physical hardware, so it may force
>   you into generating a lot of explicit intermediate
>   variables to model real hardware's behaviour 

I don't get this. After debugging, the target objects
do have adequate bit widths. A synthesis tool can
optimize away any logic not required to fill those bits.

>   (although I sense that you may feel this to be
>   a good thing rather than a disadvantage).
> 
> - Have every operation return a result whose bit width
>   is determined solely by the operand widths and the 
>   operation (VHDL).  This has the huge advantage of being
>   relatively easy to define and understand, but leads to
>   nonsenses in practice; either you get the carry-out from
>   an add, in which case it's too wide to put back into 
>   one of the operand variables, or you throw away the
>   carry as numeric_std does.  Either way, some users will
>   be forced into doing non-obvious things to get the
>   results they want.
> 
> - Have context-determined size rules.  Verilog does this,
>   and provides a fine example of how hard (impossible?) 
>   it is to get all the rules right so that people don't 
>   get nasty surprises.
> 
> It really isn't easy to make clear, reproducible rules
> that do The Right Thing for everyone's needs.  I'm not
> saying that either VHDL or Verilog have it exactly right,
> but each has an internal consistency that's fairly
> satisfying and comprehensible once you're used to it.




-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Article: 150389
Subject: Re: Verilog Book for VHDL Users
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sat, 15 Jan 2011 12:08:50 +0100
Links: << >>  << T >>  << A >>
Gabor wrote:
> On Jan 14, 11:44 am, rickman <gnu...@gmail.com> wrote:
>> I am finally going to learn Verilog for real after using VHDL for 15
>> years.  I've done a little work with Verilog and found it relatively
>> easy to use.  Now I want to learn the details and especially how not
>> to make mistakes.
>>
>> VHDL has the problem of not letting you do things unless you make it
>> explicitly clear what you want to do.  My understanding is that
>> Verilog will let you not specify fully what you want without
>> complaining, but you have to know what the default behavior will be in
>> those situations or it may not happen the way you expect.  This is
>> what I need detailed info on.
>>
>> Otherwise I am looking for something that covers synthesis well and
>> include info on writing test benches.
>>
>> I have "HDL Chip Design" by Douglas Smith, third printing 1997.  This
>> book covers both VHDL and Verilog, side by side, but has an odd style
>> and often does not cover all the details of a topic clearly.  There
>> are times I can only find the info I want if I analyze the example
>> code very, very carefully.
>>
>> Searching here I found recommendations for "The Verilog® Hardware
>> Description Language", Donald E. Thomas and "HDL Programming
>> Fundamentals: VHDL and Verilog", Nazeih Botros.  The former appears to
>> be a bit long in the tooth and the latest edition (which is the only
>> one covering the 2001 revision of the standard) is quite pricey.  The
>> latter is another dual book comparing VHDL and Verilog side by side.
>> I don't know about its organization.
>>
>> What do the Verilog users recommend in my case?  Why do you like the
>> books you like?
>>
>> Rick
> 
> As Jonathan (a true HDL guru) pointed out it's not easy to find good
> texts
> on Verilog.  I started in by modifying and adding to existing projects
> (our
> company has adopted Verilog almost exclusively) and then went back
> and read through Thomas & Moorby's book, an old text that predates
> Verilog 2001.  While I don't think the book would have been a good
> text
> without the initial dabbling in Verilog, it definitely cleared up some
> concepts
> in my mind like blocking and non-blocking assignments 


That I find really surprizing: my assessment about that book
is totally different.

Thomas & Moorby, The Verilog Hardware Description Language, 
5th edition, 2002 (updated to Verilog 2001)
===========================================================

1. Blocking assignments
-----------------------
2. The role of synthesis
------------------------

p.51 """All procedural assignments in an always block must
either be blocking or non-blocking assignments. They cannot
be mixed ... Although descriptions using the regular "="
will synthesize properly, they may not simulate properly. 
Since both simulation and synthesis are generally of
importance, use "<=" for edge sensitive circuits."""

This is a combination of two common fallacies. First, about
the use of blocking assignments: not making the difference
between synchronous communication (problematic) and
local computation (a good idea). Second, about the role
of synthesis: it is meaningless to make statements about
synthesis when a model doesn't simulate properly.

3. Blocking assignments (contradiction)
--------------------------------------

p.197 """The use of blocking and non-blocking assignments was
mixed in this specification. Non-blocking assignments were used
for registers which are used outside of the always block. For
registers used only in one always block this is not necessary ...
you can use blocking assignments to calculate intermediate
values and values only used inside the always block."""

Perfect! If only more designers would make it to this chapter :-)

The problem here is that it contradicts 1) above. Such a
contradiction within the same publication is an error in 
its own right.

4. Non-blocking assignments
---------------------------

p.205 """When using cycle-accurate specification, only one
non-blocking assignment is made to any member of the output
set in a state. If two such assignments were made to a
register, its final value would be indeterminate."""

Note: "state" in this context means the code between
clock events.

This is wrong: The last non-blocking assignment wins.
Note that this is an essential feature in RTL modeling,
for the efficient modeling of default values.

5. The nature of a reg
----------------------

p.329 """Registers are abstractions of storage devices
found in digital systems. They are defined with the
reg keyword ..."""

Linking Verilog regs to "an abstraction of storage
devices" is flawed. This is not how Verilog works and
makes it harder to understand the language.

----------------------------------------------------------


Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Article: 150390
Subject: Re: Verilog Book for VHDL Users
From: "evilkidder@googlemail.com" <evilkidder@gmail.com>
Date: Sat, 15 Jan 2011 09:33:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 15, 10:38=A0am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
> On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:
> >The former is a bit of a pig. =A0The rules that deal with arithmetic
> >over different bit widths and signed/unsigned values are just a big
> >hack in my opinion (accumulated over 30 years).
>
> I agree it's a pig - frighteningly easy to get wrong - but
> I'm not entirely sure its design is as bad as you imply.
>


Maybe the best has been made of what I consider a bad idea in the
first place.  Unfortunately, the inherent complexity in the Verilog
design doesn't just burn designers, but also tool vendors where
occasional synthesis/simulation mismatches have led to many, many
hours of head scratching and refactoring.  At least thats my
experience.



> > =A0I generally ignore [the bit width rules]
> >and use explicit wire declarations when they are needed. =A0This is
> >a nice thing in Verilog - you don't need to declare a signal first and
> >then assign to it later on - you can make new 'wires' at any point in
> >your code. =A0Generally this means when I would need a conversion
> >function in VHDL to make my types or bit widths match I will introduce
> >a new 'wire'. =A0The rules become much simpler to comprehend because of
> >this.
>
> That's a useful idea, but it does push you into a style of
> coding that's perhaps unnecessarily explicit and verbose.


Yes, it is a little bit more verbose, but if it leads to code I can
read and understand more easily (and that makes things a bit more
explicit for the toolchain), I find that worthwhile.  You may disagree
and think that less verbose code more desirable and I think that's a
valid point too.  Probably the sweet spot is somewhere in the middle.


>
> >I would also dispute the assertion that Verilog lack parameterization
> >capabilities. =A0At the module level Verilog is just as capable as
> >VHDL.
>
> I really don't think this is true, although V-2001 "generate"
> plugs some of the most gaping holes.
>


Probably the one place where VHDL has a clear practical advantage in
my mind is the ability to parameterize the port map of a circuit using
functions and/or constants from packages.  But I tend to find that
just makes Verilog a bit more verbose, not less useful as such.


> synthesis. =A0And, as you also point out, the power of VHDL's
> unconstrained subprogram arguments has no match in Verilog;
> that has an impact on design parameterization too.


Yes, that's a big win for VHDL, however, Verilog does have the ability
to parameterize functions if you package them into an (otherwise
empty) module.  It's not quite the same thing, but still useful on
occasion.


> >Personally I think both languages are hugely flawed so I wrote my own.
>
> What specific flaws have you overcome, and what new ones have
> you introduced? :-)


Obviously I am hugely biased, but ...

- Parameterization is terribly verbose in both languages and quite
limited.
- Static typing in VHDL is, again, very verbose compared to what can
be achieved using 40 year old technology (Hindley-Milner based type
systems).
- Most importantly I have a deep dislike of having to maintain a
golden model in a wholly different language in order to test my
designs.

My solution (actually, I can't take any credit for the general
approach) is to embed an HDL in a general purpose functional language
(ocaml) and build a toolset around that.  Now my parameterization
language is a full industrial strength programming language.  So is my
testbench language.  I can write everything including my golden model,
RTL and testbench in one language and I have found this leads to much
more automatic self checking testbenches which can pinpoint errors
quickly and easily without staring at waveforms all the time.

It also tickles a particular interest of mine in that it's possible to
build mini-compilers which target particular types of hardware.  That
is I can write abstract specifications of systems and then compile
then into different hardware architectures.  Good luck trying that in
Verilog!

Flaws?  The intersection between people interested in functional
programming and hardware design is, well, miniscule and is probably
mainly made up of people with 'professor' in their title.

Also, as an embedded language (or at least given it's current
implementation) it can be quite hard to relate information from later
parts in the toolchain back to the original source code ie finding the
code related to a critical path from the synthesizer.

-Andy

Article: 150391
Subject: Re: Verilog Book for VHDL Users
From: rickman <gnuarm@gmail.com>
Date: Sat, 15 Jan 2011 12:09:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 15, 12:33=A0pm, "evilkid...@googlemail.com"
<evilkid...@gmail.com> wrote:
> On Jan 15, 10:38=A0am, Jonathan Bromley <s...@oxfordbromley.plus.com>
> wrote:
>
> > On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:
> > >The former is a bit of a pig. =A0The rules that deal with arithmetic
> > >over different bit widths and signed/unsigned values are just a big
> > >hack in my opinion (accumulated over 30 years).
>
> > I agree it's a pig - frighteningly easy to get wrong - but
> > I'm not entirely sure its design is as bad as you imply.
>
> Maybe the best has been made of what I consider a bad idea in the
> first place. =A0Unfortunately, the inherent complexity in the Verilog
> design doesn't just burn designers, but also tool vendors where
> occasional synthesis/simulation mismatches have led to many, many
> hours of head scratching and refactoring. =A0At least thats my
> experience.
>
> > > =A0I generally ignore [the bit width rules]
> > >and use explicit wire declarations when they are needed. =A0This is
> > >a nice thing in Verilog - you don't need to declare a signal first and
> > >then assign to it later on - you can make new 'wires' at any point in
> > >your code. =A0Generally this means when I would need a conversion
> > >function in VHDL to make my types or bit widths match I will introduce
> > >a new 'wire'. =A0The rules become much simpler to comprehend because o=
f
> > >this.
>
> > That's a useful idea, but it does push you into a style of
> > coding that's perhaps unnecessarily explicit and verbose.
>
> Yes, it is a little bit more verbose, but if it leads to code I can
> read and understand more easily (and that makes things a bit more
> explicit for the toolchain), I find that worthwhile. =A0You may disagree
> and think that less verbose code more desirable and I think that's a
> valid point too. =A0Probably the sweet spot is somewhere in the middle.

This is starting to sound like VHDL...!  I don't mind being explicit.
It is just that in VHDL it can get rather confusing as to what you
need to be explicit about or how exactly to be explicit.

I find it hard to believe that there are no good texts on this.  In
1995 or thereabout when I was first learning VHDL, I found the texts
to be a bit lacking not to mention few.  I originally thought that
once I had gotten to a point where I could write the stuff, I would
write a book explaining how to code VHDL without learning all the
bloody details.  By the time I got ready to consider it, a bazillion
books had come out, so instead I bought a couple.  If the good Verilog
text field is really sparse, maybe I should tackle that one instead...

Rick

Article: 150392
Subject: Re: Actel Designer: how to compile VHDL top & EDIF submodule together?
From: Kryvor <kris.vorwerk@gmail.com>
Date: Sat, 15 Jan 2011 12:26:33 -0800 (PST)
Links: << >>  << T >>  << A >>
> The VHDL part has been synthesised using Synplify, producing well-
> looking EDIF. Then, I tried to compile (and I hoped then to P&R) the
> two .edn files using Actel Designer. However, here comes the failure.


One thing worth noting -- in the options for Synplify, you can make it
output tech-mapped Verilog or tech-mapped VHDL.  I tend to use those
options, myself, when debugging designs, and it sounds like doing so
in your case could you help to find the source of the disconnected
instances.


regards,
Kris

Article: 150393
Subject: Location constraints questions
From: Thomas Heller <theller@ctypes.org>
Date: Sun, 16 Jan 2011 20:04:04 +0100
Links: << >>  << T >>  << A >>
I have VHDL code that creates a tapped delay line, using the carry
chain of a spartan3 chip.  The cells (up to 128) are created in a
generate loop:

   gen_delaychain: for i in 0 to N-1 generate
     delaycell_inst : delaycell port map (
       clock    => clock,
       cin      => cy(i),
       cout     => cy(i+1),
       cout_reg => cy_reg(i));
   end generate;

As the delay chain has to run vertically through the chip (Spartan3E),
I have RLOC constraints in the UCF file:

   INST "gen_delaychain[0].delaycell_inst/MUXCY_1" RLOC="X0Y0";
   INST "gen_delaychain[1].delaycell_inst/MUXCY_1" RLOC="X0Y0";
   INST "gen_delaychain[2].delaycell_inst/MUXCY_1" RLOC="X0Y1";
   INST "gen_delaychain[2].delaycell_inst/MUXCY_1" RLOC="X0Y1";
... and so on.

First question:

Is it possible to define these contraints in the VHDL code, in the
generate loop so that I don't have to write lots of these lines?

Second question:

Is it possible to have these RLOC constraints so that the carry chain
runs vertically through the chip, and have at the same time an absolute
LOC constraint for one of these cells to specify the absolute location
of the whole chain?

Third question:

If I want to use more than one of these carry chains, how can I specify
the relative location of the cells in each chain, but let ISE determine
the y-position of the chains itself?

Thanks,
Thomas

Article: 150394
Subject: Re: Location constraints questions
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 16 Jan 2011 20:23:18 +0100
Links: << >>  << T >>  << A >>
Thomas Heller wrote:

> I have VHDL code that creates a tapped delay line, using the carry
> chain of a spartan3 chip.  The cells (up to 128) are created in a
> generate loop:

I have no answer for your questions, but are you sure it is a good idea to
use a delay line with a chain of gates? I've read that the delay can change
very much with temperature, voltage or different batches for your FPGA (if
you need it for a product). And it changes each time you change your VHDL
program and the routing is different, but maybe you can solve this with
your location constraints.

-- 
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Article: 150395
Subject: Re: Location constraints questions
From: Thomas Heller <theller@ctypes.org>
Date: Sun, 16 Jan 2011 21:07:05 +0100
Links: << >>  << T >>  << A >>
Am 16.01.2011 20:23, schrieb Frank Buss:
> Thomas Heller wrote:
>
>> I have VHDL code that creates a tapped delay line, using the carry
>> chain of a spartan3 chip.  The cells (up to 128) are created in a
>> generate loop:
>
> I have no answer for your questions, but are you sure it is a good idea to
> use a delay line with a chain of gates? I've read that the delay can change
> very much with temperature, voltage or different batches for your FPGA (if
> you need it for a product). And it changes each time you change your VHDL
> program and the routing is different, but maybe you can solve this with
> your location constraints.
>
Of course the whole chain must be calibrated, and changes in prop-delay
depending on temperature or voltage must be compensated.

I'm trying to do high-resolution timing measurements with 100ps or so
resolution, as described in several papers.  One example is this:

http://lss.fnal.gov/archive/2009/pub/fermilab-pub-09-608-e.pdf

Thomas

Article: 150396
Subject: Re: Location constraints questions
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 16 Jan 2011 21:38:40 +0100
Links: << >>  << T >>  << A >>
Thomas Heller wrote:

> Of course the whole chain must be calibrated, and changes in prop-delay
> depending on temperature or voltage must be compensated.
> 
> I'm trying to do high-resolution timing measurements with 100ps or so
> resolution, as described in several papers.  One example is this:
> 
> http://lss.fnal.gov/archive/2009/pub/fermilab-pub-09-608-e.pdf

Thanks, looks interesting.

-- 
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Article: 150397
Subject: Re: Location constraints questions
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 16 Jan 2011 21:10:25 GMT
Links: << >>  << T >>  << A >>
Thomas Heller <theller@ctypes.org> wrote:

>Am 16.01.2011 20:23, schrieb Frank Buss:
>> Thomas Heller wrote:
>>
>>> I have VHDL code that creates a tapped delay line, using the carry
>>> chain of a spartan3 chip.  The cells (up to 128) are created in a
>>> generate loop:
>>
>> I have no answer for your questions, but are you sure it is a good idea to
>> use a delay line with a chain of gates? I've read that the delay can change
>> very much with temperature, voltage or different batches for your FPGA (if
>> you need it for a product). And it changes each time you change your VHDL
>> program and the routing is different, but maybe you can solve this with
>> your location constraints.
>>
>Of course the whole chain must be calibrated, and changes in prop-delay
>depending on temperature or voltage must be compensated.
>
>I'm trying to do high-resolution timing measurements with 100ps or so
>resolution, as described in several papers.  One example is this:

If the inputsignal you are measuring consists of many events you could
try to use the delay line in the DCM to create a sampler by changing
the phase a little.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 150398
Subject: Re: Verilog Book for VHDL Users
From: Mike Treseler <mtreseler@gmail.com>
Date: Sun, 16 Jan 2011 13:36:43 -0800
Links: << >>  << T >>  << A >>
On 1/15/2011 12:09 PM, rickman wrote:

> This is starting to sound like VHDL...!  I don't mind being explicit.
> It is just that in VHDL it can get rather confusing as to what you
> need to be explicit about or how exactly to be explicit.
>
> I find it hard to believe that there are no good texts on this.

It is true.
I found this one slightly useful:
http://www.google.com/search?q=botros+isbn+1584508558

It's the only book of side by side vhdl|verilog examples in print.
But that is all it is -- simple synthesis examples and a short
explanation. No language reference or simulation examples.
But it's a quick way for a vhdl guy to get started
on verilog synthesis, and the price is right.

> In
> 1995 or thereabout when I was first learning VHDL, I found the texts
> to be a bit lacking not to mention few.  I originally thought that
> once I had gotten to a point where I could write the stuff, I would
> write a book explaining how to code VHDL without learning all the
> bloody details.  By the time I got ready to consider it, a bazillion
> books had come out, so instead I bought a couple.  If the good Verilog
> text field is really sparse, maybe I should tackle that one instead...

Maybe, but do it for fun, not for money.

        -- Mike Treseler

Article: 150399
Subject: Re: Location constraints questions
From: Thomas Heller <theller@ctypes.org>
Date: Sun, 16 Jan 2011 22:36:58 +0100
Links: << >>  << T >>  << A >>
Am 16.01.2011 22:10, schrieb Nico Coesel:
> Thomas Heller<theller@ctypes.org>  wrote:
>> I'm trying to do high-resolution timing measurements with 100ps or so
>> resolution, as described in several papers.  One example is this:
>
> If the inputsignal you are measuring consists of many events you could
> try to use the delay line in the DCM to create a sampler by changing
> the phase a little.
>
The inputsignal is not repetetive (sp?), so this is not possible.

Thomas



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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