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 147300

Article: 147300
Subject: Re: Synplify synthesis error
From: "ilaroche" <isabellelaroche@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 22 Apr 2010 08:39:20 -0500
Links: << >>  << T >>  << A >>
>Does it simulate OK?
>
>Sometimes the files need to be added in correct order, i.e.
>the file with the package must be added before any library
>units that make use of it. IIRC you can drag them around in the
>gui to alter the order, or check the .prj file which should have
>lines such as:
>add_file -lib work my_pkg.vhd
>add_file -lib work my_ent.vhd
>etc.
>
>HTH -- Pontus
>

Hi,

thanks for the answer. 

It simulates fine in Modelsim. It synthesises fine in Xilinx ISE. In
Synplify, when I click "Run", it works fine until the Mapper process where
another error happens. I've been wanting to run a Syntax and Synthesis
check to investigate that error.

I've moved my package up the list of files so it's the first one, and the
error still happens. I've also ran the Compile Only (F7) option and it
works fine! It even says that the synthax has been run successfully! Here
are the logs for both options.

Synthax Check : 


@N: CD720 :"C:\Synopsys\fpga_D201003\lib\vhd\std.vhd":123:18:123:21|Setting
time resolution to ns
@I::
"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd"
@W: CD643
:"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":10:26:10:26|Ignoring
use clause - types_viterbi not found ...
@E: CD255
:"U:\Recherche\Algo_Viterbi_Parallele\VHDL\Synplify\source\decodeur_viterbi_carre.vhd":14:42:14:42|No
identifier "poids_size" in scope

Compile Only : 


@N:CD720 : std.vhd(123) | Setting time resolution to ns
@N: : decodeur_viterbi_carre.vhd(13) | Top entity is set to
decodeur_viterbi_carre.
VHDL syntax check successful!


I'm at a loss as to what is causing the Synthax Check to fail. I'll
continue to tinker with the different options and processes, but any
further help/info would be appreciated.

Isabelle LaRoche
Université Laval
Québec, Qc, Canada	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147301
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 06:58:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 1:15=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:

> Especially with ASIC you can't verify the design by testing. There are
> so many signoff corners and modes in the timing analysis. The old
> worst/best case in normal and testmode are long gone. Even 6 corner
> analysis in 2+ modes is for low end processes with big extra margins.
> With multiple adjustable internal voltage areas, powerdown areas etc.
> the analysis is hard even with STA.

For the record, I agree that lots of static analysis is necessary
(static timing, model checking, etc.)  The thesis when I started this
sub-thread is that what the *language* gives you (VHDL vs. verilog) is
such a small subset of possible checking as to be unuseful.  I will
now add that it comes at a huge cost (in coding things just right).

Regards,
Pat

Article: 147302
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 07:03:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
.> Unfortunately, the source code is in Python :-) (MyHDL).
> However, there is equivalent converted Verilog available
> in the article.
>
> =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2

Well, maybe it's so subtle I still don't get it.  But it looks like
'run' and 'dir' are what I would consider combinatorial variables, so
I would just stuff them in the combinatorial 'always @*'  block.  The
only register which would have a corresponding 'next_' is 'q'.  In
fact, your whole sequential block could be converted to the
combinatorial block (with the exception of changing '<=3D' to '=3D', and
putting 'next_' in front of q on lhs), and the sequential block would
basically be 'q <=3D next_q'.

Or is there something else you're trying to convey that I'm missing?

Regards,
Pat

Article: 147303
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 07:29:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 9:03=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> .> Unfortunately, the source code is in Python :-) (MyHDL).
>
> > However, there is equivalent converted Verilog available
> > in the article.
>
> > =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2
>
> Well, maybe it's so subtle I still don't get it. =A0But it looks like
> 'run' and 'dir' are what I would consider combinatorial variables, so
> I would just stuff them in the combinatorial 'always @*' =A0block. =A0The
> only register which would have a corresponding 'next_' is 'q'. =A0In
> fact, your whole sequential block could be converted to the
> combinatorial block (with the exception of changing '<=3D' to '=3D', and
> putting 'next_' in front of q on lhs), and the sequential block would
> basically be 'q <=3D next_q'.
>
> Or is there something else you're trying to convey that I'm missing?
>
> Regards,
> Pat

BTW, your myhdl does something similar, in that you use 'q.next'.  So,
I really don't understand why you would think it's a terrible thing to
use 'next_q' to mean the same thing.

Regards,
Pat

Article: 147304
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: Eric <eric.laforest@gmail.com>
Date: Thu, 22 Apr 2010 07:52:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 21, 6:26=A0am, John_H <newsgr...@johnhandwork.com> wrote:
> Could you mention here or on your page what you mean by
> "multipumping?" =A0If you mean time multiplexed access, I can see why
> multipumping is bad. =A0[The "pure logic" approach also isn't obvious.]

Yes, multipumping is time-multiplexing. It's not entirely bad, as
there may be a speed margin leftover that you can trade for area using
multipumping. Also, it is useful if you have few ports or low speed
requirements.

Pure logic refers simply to using only the reconfigurable fabric of
the FPGA to implement the memory. It's not a very scalable
solution. :)

> Do you update the LVT in the same way I might update the RAM value in
> a many-write BlockRAM?

No. We've had several independent mentions of using XOR, but we hadn't
heard of it at the time. We'll be looking at it in the future. The LVT
is implemented in pure logic and has multiple read and write ports
which can all work simultaneously. It remains practical because it is
very narrow (log2(# of write ports) instead of full data word width).

> Aside from wide data, however, I don't see (without going into the
> attachments on that page) how updating the LVT is any different than
> updating the memory in the first place.

The LVT manages a bunch of Block RAMs with only one write and one read
port, making them all behave as a single multiported memory. The LVT
simply keeps track of which port last wrote to each address. Since the
actual data is stored in Block RAMs, the end result is faster and more
area efficient than other approaches.

Please let me know if you have more questions.

Eric

Article: 147305
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 22 Apr 2010 08:01:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 4:29=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 9:03=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
>
>
>
> > On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> > .> Unfortunately, the source code is in Python :-) (MyHDL).
>
> > > However, there is equivalent converted Verilog available
> > > in the article.
>
> > > =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2
>
> > Well, maybe it's so subtle I still don't get it. =A0But it looks like
> > 'run' and 'dir' are what I would consider combinatorial variables, so
> > I would just stuff them in the combinatorial 'always @*' =A0block. =A0T=
he
> > only register which would have a corresponding 'next_' is 'q'. =A0In
> > fact, your whole sequential block could be converted to the
> > combinatorial block (with the exception of changing '<=3D' to '=3D', an=
d
> > putting 'next_' in front of q on lhs), and the sequential block would
> > basically be 'q <=3D next_q'.
>
> > Or is there something else you're trying to convey that I'm missing?
>
> > Regards,
> > Pat
>
> BTW, your myhdl does something similar, in that you use 'q.next'. =A0So,
> I really don't understand why you would think it's a terrible thing to
> use 'next_q' to mean the same thing.

The two are unrelated. q.next is MyHDL's way to do
signal (non blocking) assignment ("<=3D").

My critique is that you use 2 signals/regs per state register
instead of 1. You could also do that in MyHDL, but I'm not doing
that in the examples I showed you. BTW, it would look like:
   next_q.next =3D q

Jan


Article: 147306
Subject: OFFSET and OFFSET out
From: "newbab22" <kumar1983.s@n_o_s_p_a_m.gmail.com>
Date: Thu, 22 Apr 2010 10:04:43 -0500
Links: << >>  << T >>  << A >>
Hi All,

 

What is OFFSET In and OFFSET OUT ? Is it setup and hold time of Flip flop?.
How to set a Offset in And offset out Constraints for a particular design?

 

In synthesis report I'm seeing Minimum Input arrival time and Max.Output
required time? whether it is equivalent to Offset in and Offset out ?

 

Please give some idea about this.

 

Thanks

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

Article: 147307
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 22 Apr 2010 08:08:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 4:03=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 3:44=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> .> Unfortunately, the source code is in Python :-) (MyHDL).
>
> > However, there is equivalent converted Verilog available
> > in the article.
>
> > =A0 =A0http://www.myhdl.org/doku.php/cookbook:jc2
>
> Well, maybe it's so subtle I still don't get it. =A0But it looks like
> 'run' and 'dir' are what I would consider combinatorial variables, so
> I would just stuff them in the combinatorial 'always @*' =A0block. =A0The
> only register which would have a corresponding 'next_' is 'q'. =A0In
> fact, your whole sequential block could be converted to the
> combinatorial block (with the exception of changing '<=3D' to '=3D', and
> putting 'next_' in front of q on lhs), and the sequential block would
> basically be 'q <=3D next_q'.
>
> Or is there something else you're trying to convey that I'm missing?

Yes, the fact that 'run' and 'dir' are state variables. Therefore,
your
proposed approach wouldn't work. You have the test vectors, you can
try it yourself.

Quoting from the article:
"""
This example is more subtle and complex than it may seem at first
sight. As said before, variables dir and run are state variables and
will therefore require a flip-flop in an implementation. However, they
are also used =93combinatorially=94: when they change, they may influence
the counter operation =93in the same clock cycle=94, that is, before the
flip-flop output changes. This is perfectly fine behavior and no
problem for synthesis tools, but it tends to confuse a lot of
designers.
"""

Jan

Article: 147308
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: rickman <gnuarm@gmail.com>
Date: Thu, 22 Apr 2010 09:36:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 10:52 am, Eric <eric.lafor...@gmail.com> wrote:
> On Apr 21, 6:26 am, John_H <newsgr...@johnhandwork.com> wrote:
>
> > Could you mention here or on your page what you mean by
> > "multipumping?"  If you mean time multiplexed access, I can see why
> > multipumping is bad.  [The "pure logic" approach also isn't obvious.]
>
> Yes, multipumping is time-multiplexing. It's not entirely bad, as
> there may be a speed margin leftover that you can trade for area using
> multipumping. Also, it is useful if you have few ports or low speed
> requirements.
>
> Pure logic refers simply to using only the reconfigurable fabric of
> the FPGA to implement the memory. It's not a very scalable
> solution. :)
>
> > Do you update the LVT in the same way I might update the RAM value in
> > a many-write BlockRAM?
>
> No. We've had several independent mentions of using XOR, but we hadn't
> heard of it at the time. We'll be looking at it in the future. The LVT
> is implemented in pure logic and has multiple read and write ports
> which can all work simultaneously. It remains practical because it is
> very narrow (log2(# of write ports) instead of full data word width).
>
> > Aside from wide data, however, I don't see (without going into the
> > attachments on that page) how updating the LVT is any different than
> > updating the memory in the first place.
>
> The LVT manages a bunch of Block RAMs with only one write and one read
> port, making them all behave as a single multiported memory. The LVT
> simply keeps track of which port last wrote to each address. Since the
> actual data is stored in Block RAMs, the end result is faster and more
> area efficient than other approaches.
>
> Please let me know if you have more questions.
>
> Eric

I guess I don't understand what you are accomplishing with this.
Block rams in FPGAs are almost always multiported.  Maybe not N way
ported, but you assume they are single ported when they are dual
ported.

Can you give a general overview of what you are doing without using
jargon?  I took a look and didn't get it at first glance.

Rick

Article: 147309
Subject: Can Altera generate EDIF
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 22 Apr 2010 17:48:06 +0100
Links: << >>  << T >>  << A >>
Hi all,

Can Quartus be persuaded to *output* an EDIF netlist of the design
(at any point in the compilation)?  Google returns lots of links about
the EDIF import capabilities, but I can't see any on exporting!

Why? I've started on an EDF reader for FPGAOptim so you can easily
figure out what's going on with designs which don't fit in the device,
from the Xilinx NGC file - using NGC2EDIF).  It occurred to me that
having EDIF input would make the tool useful for other FPGAs.

While I'm at it, does Altera have an equivalent of Xilinx's XDL
format? XDL is a low-level textual description of the configuration of
the device in terms of what the LUTs are configured as, which of the
config muxes are set, what routing is used etc.

Thanks!
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
http://www.conekt.net/fpgaoptim.html

Article: 147310
Subject: Re: Can Altera generate EDIF
From: "HT-Lab" <hans64@ht-lab.com>
Date: Thu, 22 Apr 2010 17:51:50 +0100
Links: << >>  << T >>  << A >>

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message 
news:uvdbjsabd.fsf@trw.com...
> Hi all,
>
> Can Quartus be persuaded to *output* an EDIF netlist of the design
> (at any point in the compilation)?  Google returns lots of links about
> the EDIF import capabilities, but I can't see any on exporting!

I suspect not, even Mentor's Precision now generates a VQM file instead of EDIF 
for Altera,

Hans
www.ht-lab.com


>
> Why? I've started on an EDF reader for FPGAOptim so you can easily
> figure out what's going on with designs which don't fit in the device,
> from the Xilinx NGC file - using NGC2EDIF).  It occurred to me that
> having EDIF input would make the tool useful for other FPGAs.
>
> While I'm at it, does Altera have an equivalent of Xilinx's XDL
> format? XDL is a low-level textual description of the configuration of
> the device in terms of what the LUTs are configured as, which of the
> config muxes are set, what routing is used etc.
>
> Thanks!
> Martin
>
> -- 
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.conekt.net/electronics.html
> http://www.conekt.net/fpgaoptim.html 



Article: 147311
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: Eric <eric.laforest@gmail.com>
Date: Thu, 22 Apr 2010 10:55:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 12:36=A0pm, rickman <gnu...@gmail.com> wrote:
> I guess I don't understand what you are accomplishing with this.
> Block rams in FPGAs are almost always multiported. =A0Maybe not N way
> ported, but you assume they are single ported when they are dual
> ported.

But what if you want more ports, say 2-write/4-read, without wait
states?
I assume them to be "simply dual-ported", which means one write port
and one read port, both operating concurrently. It is also possible to
run them in "true dual port" mode, where each port can either read or
write in a cycle. Some of the designs in the paper do that.

> Can you give a general overview of what you are doing without using
> jargon? =A0I took a look and didn't get it at first glance.

OK. Let me try:

Assume a big, apparently multiported memory of some given capacity and
number of ports. Inside it, I use a small multiported memory
implemented using only the fabric of an FPGA, which stores only the
number of the write port which wrote last to a given address. Thus
this small memory is of the same depth as the whole memory, but much
narrower, hence it scales better.

When you read at a given address from the big memory, internally you
use that address to look up which write port wrote there last, and use
that information to steer the read to the correct internal memory bank
which will hold the data you want. These banks are built-up of
multiple Block RAMs so as to have one write port each, and as many
read ports as the big memory appears to have.

The net result is a memory which appears to have multiple read and
write ports which can all work simultaneously, but which leaves the
bulk of the storage to Block RAMs instead of the FPGA fabric, which
makes for better speed and smaller area.

Does that help?

Eric

Article: 147312
Subject: How to over clock for DSP48
From: fl <rxjwg98@gmail.com>
Date: Thu, 22 Apr 2010 11:53:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
We are developing algorithm on a LYRTech ADC board. There are only 96
DSP48 on this board. We have a problem of DSP shortage with a FIR
rcosine and low pass FIR design. There is a 105 MHz clock source with
this board. I think a solution is to over clock DSP48 to improve
performance. My question is how to double, triple or quadruple 105MHz
on board clock. Can DCM do the trick? Then, how to get that? Thanks a
lot.

Article: 147313
Subject: Re: How to over clock for DSP48
From: fl <rxjwg98@gmail.com>
Date: Thu, 22 Apr 2010 11:58:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 2:53=A0pm, fl <rxjw...@gmail.com> wrote:
> Hi,
> We are developing algorithm on a LYRTech ADC board. There are only 96
> DSP48 on this board. We have a problem of DSP shortage with a FIR
> rcosine and low pass FIR design. There is a 105 MHz clock source with
> this board. I think a solution is to over clock DSP48 to improve
> performance. My question is how to double, triple or quadruple 105MHz
> on board clock. Can DCM do the trick? Then, how to get that? Thanks a
> lot.

This is a up-converter design from 25.1MSPS to 105MSPS. Any
suggestions on the design? Thanks.

Article: 147314
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 12:11:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 10:08=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> > Or is there something else you're trying to convey that I'm missing?
>
> Yes, the fact that 'run' and 'dir' are state variables. Therefore,
> your
> proposed approach wouldn't work. You have the test vectors, you can
> try it yourself.
>
> Quoting from the article:
> """
> This example is more subtle and complex than it may seem at first
> sight. As said before, variables dir and run are state variables and
> will therefore require a flip-flop in an implementation. However, they
> are also used =93combinatorially=94: when they change, they may influence
> the counter operation =93in the same clock cycle=94, that is, before the
> flip-flop output changes. This is perfectly fine behavior and no
> problem for synthesis tools, but it tends to confuse a lot of
> designers.
> """

OK, I admit I didn't read that carefully enough; in fact, I just
glanced at the actual code before my coffee this morning.  But you
know what?  Where I come from, "subtle" that "tends to confuse a lot
of designers" is just a synonym for "screwed up."

The whole point of the coding style I was describing is to NOT write
stuff that would confuse other designers.  After all, in C I can write
perfectly valid code like "0[x] =3D 3".  But just because I can, doesn't
mean it's a good idea.

Regards,
Pat

Article: 147315
Subject: Problem with data2mem
From: Wipster <benwhitten@gmail.com>
Date: Thu, 22 Apr 2010 12:25:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
The age old problem it seems data2mem and BMM files and I am stuck
with a new problem I cant find the answer for.
I have some generic ram in verilog which the xilinx software suite
looks at and maps to two RAMB16s (higher two bytes and lower two
bytes) so I have made a BMM file with the right names and widths
depths etc Thats fine, it recognizes them and updates the _bd.bmm with
the locations they have been mapped too.
However the CPU does not turn over, I did a bit of digging and did a
dump of working and non working BRAM data, it seems that on the
working dump the higher two byte block is bit-shifted right 2 (I'm
guessing because readmemh uses the parity as the lsbs).
Is there a way I can tell data2mem that I want the parity on the other
side or not atall so it inserts the code properly because its giving
an offset when it inserts, its also interesting to note that the lower
block matches perfectly?
I have tried using RAMB18 but that didn't generate anything that
looked right. Here is the working, two bit shifted, readmemh output:
http://pastebin.com/0hgNpAnP and here is the non working data2mem, non
bit shifted version: http://pastebin.com/Tcs3PJjZ

Much thanks,
Ben

Article: 147316
Subject: Re: I'd rather switch than fight!
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 22 Apr 2010 13:04:30 -0700
Links: << >>  << T >>  << A >>
On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe
<jan@jandecaluwe.com> wrote:

>On Apr 22, 4:03 pm, Patrick Maupin <pmau...@gmail.com> wrote:
>> On Apr 22, 3:44 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>> .> Unfortunately, the source code is in Python :-) (MyHDL).
>>
>> > However, there is equivalent converted Verilog available
>> > in the article.
>>
>> >    http://www.myhdl.org/doku.php/cookbook:jc2
>>
>> Well, maybe it's so subtle I still don't get it.  But it looks like
>> 'run' and 'dir' are what I would consider combinatorial variables, so
>> I would just stuff them in the combinatorial 'always @*'  block.  The
>> only register which would have a corresponding 'next_' is 'q'.  In
>> fact, your whole sequential block could be converted to the
>> combinatorial block (with the exception of changing '<=' to '=', and
>> putting 'next_' in front of q on lhs), and the sequential block would
>> basically be 'q <= next_q'.
>>
>> Or is there something else you're trying to convey that I'm missing?
>
>Yes, the fact that 'run' and 'dir' are state variables. Therefore,
>your
>proposed approach wouldn't work. You have the test vectors, you can
>try it yourself.
>
>Quoting from the article:
>"""
>This example is more subtle and complex than it may seem at first
>sight. As said before, variables dir and run are state variables and
>will therefore require a flip-flop in an implementation. However, they
>are also used “combinatorially”: when they change, they may influence
>the counter operation “in the same clock cycle”, that is, before the
>flip-flop output changes. This is perfectly fine behavior and no
>problem for synthesis tools, but it tends to confuse a lot of
>designers.
>"""

I am not sure who is really confused here. What is suggested in the
above paragraph is not really feasible; assuming by 'dir' one refers
to the output of a flop. It's not possible to use the output of a flop
at the same clock when its input changes (without generating an
intentional hold violation by playing with clock skews). What one can
do  is to have a combinational signal dir_d which gets computed by
dir_q and other signals. This dir_d can be used in the same clock
cycle but dir_q will not be available till next cycle:

if (left or dir_q) dir_d = 1; 
if (right) dir_d = 0;

if (dir_d) do_left;
dir_q <= dir_d;

The problem with the last verilog block shown is the dir and run are
not flops anymore but combinational signals decoded from goleft and
goright so the last direction will not be remembered. If last
direction needs to be remembered, one needs to decode the
'instruction', use  the decoded value and remember the decoded value
as above.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 147317
Subject: Re: Synplify synthesis error
From: Pontus <pontus.stenstrom@gmail.com>
Date: Thu, 22 Apr 2010 13:40:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
Could you try to introduce an error in the package declaration,
just to see that the compiler/analyzer is actually looking
at the file you think its looking at?!?
-- Pontus

Article: 147318
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 22 Apr 2010 14:21:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 9:11=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 22, 10:08=A0am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>
>
>
> > > Or is there something else you're trying to convey that I'm missing?
>
> > Yes, the fact that 'run' and 'dir' are state variables. Therefore,
> > your
> > proposed approach wouldn't work. You have the test vectors, you can
> > try it yourself.
>
> > Quoting from the article:
> > """
> > This example is more subtle and complex than it may seem at first
> > sight. As said before, variables dir and run are state variables and
> > will therefore require a flip-flop in an implementation. However, they
> > are also used =93combinatorially=94: when they change, they may influen=
ce
> > the counter operation =93in the same clock cycle=94, that is, before th=
e
> > flip-flop output changes. This is perfectly fine behavior and no
> > problem for synthesis tools, but it tends to confuse a lot of
> > designers.
> > """
>
> OK, I admit I didn't read that carefully enough; in fact, I just
> glanced at the actual code before my coffee this morning. =A0But you
> know what? =A0Where I come from, "subtle" that "tends to confuse a lot
> of designers" is just a synonym for "screwed up."

Let me put it more correctly. Initially, I think, everyone is confused
about this. I know I was (20 years ago already!). The confusion
is resolved by a new insight: how RTL synthesis *really* works.
Some get it quickly, others need more time.
I think that's a common pattern with new paradigms.

The benefit: a coding technique to solve real problems
significantly more elegantly.

> The whole point of the coding style I was describing is to NOT write
> stuff that would confuse other designers. =A0After all, in C I can write
> perfectly valid code like "0[x] =3D 3". =A0But just because I can, doesn'=
t
> mean it's a good idea.

I suggest you try your coding style with my examples. You have the
spec and test vectors. If you find your code much clearer, I don't
have
a case (with you) to argue further. Otherwise, you'll remember me
when you start applying this technique in your designs :-)

Jan

Article: 147319
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 14:37:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 3:04=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe
> >This example is more subtle and complex than it may seem at first
> >sight. As said before, variables dir and run are state variables and
> >will therefore require a flip-flop in an implementation. However, they
> >are also used =93combinatorially=94: when they change, they may influenc=
e
> >the counter operation =93in the same clock cycle=94, that is, before the
> >flip-flop output changes. This is perfectly fine behavior and no
> >problem for synthesis tools, but it tends to confuse a lot of
> >designers.
>
> I am not sure who is really confused here. What is suggested in the
> above paragraph is not really feasible; assuming by 'dir' one refers
> to the output of a flop. It's not possible to use the output of a flop
> at the same clock when its input changes (without generating an
> intentional hold violation by playing with clock skews). What one can
> do =A0is to have a combinational signal dir_d which gets computed by
> dir_q and other signals. This dir_d can be used in the same clock
> cycle but dir_q will not be available till next cycle:

I don't think Jan is confused.  While I haven't actually simulated it,
I have no reason to disbelieve that he has built a flop which feeds
into a combinatorial network, and the only thing here with a name is
the output of the combinatorial network, which also happens to feed
back into the flop.

Verilog will certainly let you do such things.  And now (I think) I
understand a bit better what Jan means by "register inferencing" -- in
this case, this capability is manifested by the ability to not give a
name to a register itself, but only to the combinatorial net feeding
the register.

When I first started using Verilog, I would do such things, and
confuse myself and others mightily.  So I stand by my opinion that
having two distinct yet related names for the input and output of a
hardware register makes it easier for someone to pick up some code and
conceptualize what is going on and not get it wrong at first glance.
FWIW, in a case like this, rather than having 'next_dir' and 'dir', I
might use 'dir' and 'prev_dir'.  So the start of the combinatorial
block could have "dir =3D prev_dir", followed by conditionally setting
dir as required.  Then in the synchronous block, you would have
"prev_dir =3D dir".

As I originally mentioned, this style is a bit more verbose, but since
code is read much more often than it is written, it is a net win.

Regards,
Pat

Article: 147320
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 14:40:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 4:21=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:

> Let me put it more correctly. Initially, I think, everyone is confused
> about this. I know I was (20 years ago already!). The confusion
> is resolved by a new insight: how RTL synthesis *really* works.

I got it.  In fact, I used to do what you said, but sometimes I would
be confused, or others would be.  Haven't done that in 15 years.

> Some get it quickly, others need more time.
> I think that's a common pattern with new paradigms.

That's an old paradigm.

> The benefit: a coding technique to solve real problems
> significantly more elegantly.

But, in my previous experience, it doesn't.  It just confuses people.

> I suggest you try your coding style with my examples. You have the
> spec and test vectors. If you find your code much clearer, I don't
> have
> a case (with you) to argue further. Otherwise, you'll remember me
> when you start applying this technique in your designs :-)

Been there, done that, got the t-shirt; somebody else showed me the
light over a decade ago, and I never went back.

Regards,
Pat

Article: 147321
Subject: Re: Need to run old 8051 firmware
From: George Neuner <gneuner2@comcast.net>
Date: Thu, 22 Apr 2010 18:03:07 -0400
Links: << >>  << T >>  << A >>
On Tue, 20 Apr 2010 18:14:05 -0700 (PDT), Derek Simmons
<dereks314@gmail.com> wrote:

Completely off topic, but ...

>I recently interviewed with a avionics company that uses [8031/8051]
>for digital displays in the cockpit of the plane (it is easy to get
>certfied for the FAA).

I've never heard FAA certification described as "easy".  Maybe they
rubber-stamp for established vendors and members of the "old boys"
club.  From what I've heard wandering air shows, they actively prevent
small businesses from entering the market.

I don't have personal experience with FAA device cert ... I haven't
built my plane yet and my pilot license so far has provided quite
enough contact with them to satisfy my masochistic streak.  However, I
have dealt professionally with the FDA, and if the FAA is in any way
similar they really ought to be a PITA.

George

Article: 147322
Subject: Re: I'd rather switch than fight!
From: Andy <jonesandy@comcast.net>
Date: Thu, 22 Apr 2010 15:32:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Other than twice the declarations, unintentional latches, explicitly
coding clock enables, simulation penalties, etc., using separate
combinatorial and sequential blocks is just fine.

Most designers here use single clocked processes / always blocks.
Those that don't are 'encouraged' to.

Andy

Article: 147323
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 22 Apr 2010 15:36:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 5:32=A0pm, Andy <jonesa...@comcast.net> wrote:
> Other than twice the declarations, unintentional latches, explicitly
> coding clock enables, simulation penalties, etc., using separate
> combinatorial and sequential blocks is just fine.

Unintentional latches don't happen if you use a consistent naming
style with, e.g. 'next_x' and 'x'.

I don't think simulation penalties happen if the simulator is halfway
decent.

Twice the declarations is a slight issue, but if you do reg [2:0] x,
next_x; it's not too bad at all.

Explicitly coding clock enables -- not sure what you mean here --
that's an if statement no matter how you slice it.

Regards,
Pat

Article: 147324
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 22 Apr 2010 15:45:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 22, 1:55=A0pm, Eric <eric.lafor...@gmail.com> wrote:
> On Apr 22, 12:36=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > I guess I don't understand what you are accomplishing with this.
> > Block rams in FPGAs are almost always multiported. =A0Maybe not N way
> > ported, but you assume they are single ported when they are dual
> > ported.
>
> But what if you want more ports, say 2-write/4-read, without wait
> states?
> I assume them to be "simply dual-ported", which means one write port
> and one read port, both operating concurrently. It is also possible to
> run them in "true dual port" mode, where each port can either read or
> write in a cycle. Some of the designs in the paper do that.
>
> > Can you give a general overview of what you are doing without using
> > jargon? =A0I took a look and didn't get it at first glance.
>
> OK. Let me try:
>
> Assume a big, apparently multiported memory of some given capacity and
> number of ports. Inside it, I use a small multiported memory
> implemented using only the fabric of an FPGA, which stores only the
> number of the write port which wrote last to a given address. Thus
> this small memory is of the same depth as the whole memory, but much
> narrower, hence it scales better.
>
> When you read at a given address from the big memory, internally you
> use that address to look up which write port wrote there last, and use
> that information to steer the read to the correct internal memory bank
> which will hold the data you want. These banks are built-up of
> multiple Block RAMs so as to have one write port each, and as many
> read ports as the big memory appears to have.
>
> The net result is a memory which appears to have multiple read and
> write ports which can all work simultaneously, but which leaves the
> bulk of the storage to Block RAMs instead of the FPGA fabric, which
> makes for better speed and smaller area.
>
> Does that help?
>
> Eric

I appreciate the elaboration here in the newsgroup.

The "true dual port" nature of the BlockRAMs allows one independent
address on each of the two ports with a separate write enable for each
port.  The behavior of the BlockRAM can be modified to provide read
data based on the new write data, old data, or no change in the read
data value from last cycle (particularly helpful for multi-pumping).

For an M write, N read memory, your approach appears to need M x (N+1)
memories since you can have M writes all happening at the same time N
accesses are made to the same "most recently written" memory.  Please
correct me if I'm wrong.  This is the same number of memories required
with the XOR approach but without the LVT overhead.  The time delay in
reading the LVT and multiplexing the memories feels like it would be
cumbersome.  While this might not add "wait states" it appears the
system would not be able to run terribly quickly.  XORs are pretty
quick.

There are always more ways to approach a problem that any one group
can come up with.  Kudos on your effort to bring a better approach to
a tough system level issue for difficult designs.



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