EDK : FSL macros defined by Xilinx are wrong

[Nico Coesel]

PFC <lists@peufeu.com> wrote:

If you are going to do multi-channel audio, Xilinx may have the
advantage that you can use the LUTs as 16x1 memory instead of
flipflops. If you want to process up to 16 channels, you can use luts
as temporary storage for filter results etc. The space savings can be
huge.

For the FIR I will probably use some BRAM but I was looking into this the
other day and I really like the tiny FIFOs you can make with the Xilinx
parts. Very useful for me ! I can instantiate one FIFO per channel using
very little slices and it greatly simplifies my data flow. And the SRLs
are nice to make audio I²S encoders, too.

Why FIR? AFAIK it takes less logic to implement an IIR filter.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[Icky Thwacket]

"Aiken" <aikenpang@gmail.com> wrote in message
news:0eaf6519-6902-42c2-8686-79be14ba6ba8@t54g2000hsg.googlegroups.com...

What's the difference between target and the result freq.?

What yer want v. what yer get

 

[Icky Thwacket]

"Aiken" <aikenpang@gmail.com> wrote in message
news:0eaf6519-6902-42c2-8686-79be14ba6ba8@t54g2000hsg.googlegroups.com...

What's the difference between target and the result freq.?

What yer want v. what yer get

 

[jtw]

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:f1ac06eb-bd12-4ff5-a9bd-f88d2abb7104@k37g2000hsf.googlegroups.com...
On Jun 6, 12:48 pm, JeDi <jaydev.she...@gmail.com> wrote:
... snip..

"The tools will often produce sub-optimal solutions when trying to
solve many simultaneous, conflicting requirements (resource location,
timing, ...), and
thus have trouble for the total design. Generally, the timing
performance achieved at the chip level is less optimal that at the
block level, so make sure your blocks will meet timing. Other (non-
coding) tricks: location constraints, multi-cycle constraints,"

So true !! I have seen exactly this - block level everything is
fine .. but chip level ... performance starts deteriorating !! I have
tried the resource allocation and timing constraints also. Though
these improve the frequency a little, I think the biggest constraint
comes from the very high logic utilization and hence the tool is not
able to concentrate its efforts efficiently !!! However, I am working
on a few things ... lets see if the efforts pay dividends !!!

Saying that each block has good performance but tying them all
together is a problem caused by 'sub-optimal' placement is without any
basis. While it could be a contributor, the most likely cause is not
the synthesis tool but the algorithm you're trying to implement.

Look at your worst case timing path. If you see it going through a
whole bunch of levels of logic, then it's not the synthesis tool's
poor placement, it's your logic. If you see only one or two levels of
logic and unreasonably long delays then it is either the synthesis
tool (as you suggest) or you have an unrealistic expectation of what
kind of clock speed you can expect to run at.

Good luck

Kevin Jennings


-----

I have seen specific cases where the synthesizer gets carried away
optimizing away redundant logic; e.g., several instances of the same logic.
When the individual block is sent through synthesis and then place & route,
everything is fine; when the chip, containing multiple copies of the logic,
is sent through, the synthesizer perceives (correctly) redundant logic.
Unfortunately, in my case it made par work much harder, because of the
increase in fanout (more spacing/distribution than number of loads.) When I
synthesized the block independently, and then did the top-level sim with the
several instances appearing as black boxes, the chip-level place & route
improved significantly, achieving timing closure.

I often run low-level blocks through preliminary synthesis & par, even when
I don't do black-box instantiation, to give me that realistic expectation.
I try to find out the limits of performance here, not just that it meets my
'top-level' timing; if it just barely meets at the low-level, I expect
trouble later.... It also gives me the opportunity to experiment with
different optimization schemes (coding style, re-architecting, synthesis
directives, etc.) with a quick turnaround. In many of my designs, some
blocks may be used 4 or more times; the more times, the more relevant to
optimize for utilization, particularly when pushing the limits
(space/routing/speed.)

JTW

 

[Nico Coesel]

"jtw" <wrightjt @hotmail.invalid> wrote:

I disagree; however, I would include 'pipelining' as part of the coding
style/trick. You can also try to code such that the critical path(s) with
have small enough blocks of logic between flip-flops to enable timing
closure. You may add attributes to signals to try to coerce the synthesizer
into doing 'the right thing'; if it doesn't come automatically, you might do
some low-level coding, synthesize that, and then use the resultant edif file
as a black box to the the next level up.

Before troubling with all that, though, do some bottom-up evaluations,
particularly of things you feel will have trouble meeting timing. The tools
will often produce sub-optimal solutions when trying to solve many
simultaneous, conflicting requirements (resource location, timing, ...), and
thus have trouble for the total design. Generally, the timing performance
achieved at the chip level is less optimal that at the block level, so make
sure your blocks will meet timing. If they do, and the whole doesn't, you
might try incremental design techniques, where you solve one problem, build
on it for the next, etc... If they don't, you can try re-coding and/or
re-architecting to get the block(s) to meet timing, and then try the whole.
Solve the relatively simple problems first... and sometimes the big problems
become simple.

Other (non-coding) tricks: location constraints, multi-cycle constraints,

This will work, but the time involved to get the design finished will
increase exponentially. A simpler way to do the same is using more
than one clock. I usually have 3 clocks: slow (several MHz), main
processes (tens of MHz) and high speed.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[jtw]

"Nico Coesel" <nico@puntnl.niks> wrote in message
news:484abd50.3010252544@news.planet.nl...

"jtw" <wrightjt @hotmail.invalid> wrote:

I disagree; however, I would include 'pipelining' as part of the coding
style/trick. You can also try to code such that the critical path(s) with
have small enough blocks of logic between flip-flops to enable timing
closure. You may add attributes to signals to try to coerce the
synthesizer
into doing 'the right thing'; if it doesn't come automatically, you might
do
some low-level coding, synthesize that, and then use the resultant edif
file
as a black box to the the next level up.

Before troubling with all that, though, do some bottom-up evaluations,
particularly of things you feel will have trouble meeting timing. The
tools
will often produce sub-optimal solutions when trying to solve many
simultaneous, conflicting requirements (resource location, timing, ...),
and
thus have trouble for the total design. Generally, the timing performance
achieved at the chip level is less optimal that at the block level, so
make
sure your blocks will meet timing. If they do, and the whole doesn't, you
might try incremental design techniques, where you solve one problem,
build
on it for the next, etc... If they don't, you can try re-coding and/or
re-architecting to get the block(s) to meet timing, and then try the
whole.
Solve the relatively simple problems first... and sometimes the big
problems
become simple.

Other (non-coding) tricks: location constraints, multi-cycle constraints,

This will work, but the time involved to get the design finished will
increase exponentially. A simpler way to do the same is using more
than one clock. I usually have 3 clocks: slow (several MHz), main
processes (tens of MHz) and high speed.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Somehow, several of the designs I recently finished had:
320 MHz+ data clock, DDR
160 MHz+, coherent with data clock
160 MHz+, system clock
80 MHz+, system clock coherent with 160 MHz system clock

I still used multi-cycle constraints, TIG (Timing Ignore) constraints,
location constraints, .... and had to 'play tricks' to force the tool not to
remove redundant FFs, and insert FFs to break up combinational logic, and
....

Adding clocks will not particularly make meeting timing easier; it is
comparable to using multi-cycle constraints, which imply a virtual clock.
(It may add value in power saving on the clock trees.) Adding clocks adds
complexity, because now you must manage the clock domain crossings. But,
sometimes, that is just part of the job...

JTW

 

[jtw]

"Nico Coesel" <nico@puntnl.niks> wrote in message
news:484abd50.3010252544@news.planet.nl...

"jtw" <wrightjt @hotmail.invalid> wrote:

I disagree; however, I would include 'pipelining' as part of the coding
style/trick. You can also try to code such that the critical path(s) with
have small enough blocks of logic between flip-flops to enable timing
closure. You may add attributes to signals to try to coerce the
synthesizer
into doing 'the right thing'; if it doesn't come automatically, you might
do
some low-level coding, synthesize that, and then use the resultant edif
file
as a black box to the the next level up.

Before troubling with all that, though, do some bottom-up evaluations,
particularly of things you feel will have trouble meeting timing. The
tools
will often produce sub-optimal solutions when trying to solve many
simultaneous, conflicting requirements (resource location, timing, ...),
and
thus have trouble for the total design. Generally, the timing performance
achieved at the chip level is less optimal that at the block level, so
make
sure your blocks will meet timing. If they do, and the whole doesn't, you
might try incremental design techniques, where you solve one problem,
build
on it for the next, etc... If they don't, you can try re-coding and/or
re-architecting to get the block(s) to meet timing, and then try the
whole.
Solve the relatively simple problems first... and sometimes the big
problems
become simple.

Other (non-coding) tricks: location constraints, multi-cycle constraints,

This will work, but the time involved to get the design finished will
increase exponentially. A simpler way to do the same is using more
than one clock. I usually have 3 clocks: slow (several MHz), main
processes (tens of MHz) and high speed.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Somehow, several of the designs I recently finished had:
320 MHz+ data clock, DDR
160 MHz+, coherent with data clock
160 MHz+, system clock
80 MHz+, system clock coherent with 160 MHz system clock

I still used multi-cycle constraints, TIG (Timing Ignore) constraints,
location constraints, .... and had to 'play tricks' to force the tool not to
remove redundant FFs, and insert FFs to break up combinational logic, and
....

Adding clocks will not particularly make meeting timing easier; it is
comparable to using multi-cycle constraints, which imply a virtual clock.
(It may add value in power saving on the clock trees.) Adding clocks adds
complexity, because now you must manage the clock domain crossings. But,
sometimes, that is just part of the job...

JTW

 

[Symon]

faza wrote:

Faza:Still iam unable to trace how Fs will decide Fclk :

Hi Faza,

I'll have a go.
Design your filter with Fs = 1 .
Let's say you designed it with a cutoff frequency of Fc where Fc < Fs/2 .
If you then clock this filter with a frequency of kFs, the cut off frequency
will be kFc .
Mmmm, hotwings.

HTH., Syms.

 

[Symon]

Andy Botterill wrote:

Using verilog and ISE 10.1.

I add a reg to modify the design's behaviour. It works and it works
correctly. The change is intended to invert the carry logic for some
op-codes.

However synthesis , using XST , gives the following warning message.

WARNING:Xst:646 - Signal <borrow> is assigned but never used. This
unconnected signal will be trimmed during the optimization process.

Hi Andy,

Do you have a signal such as 'carry' which is the exact inverse of 'borrow'?
I.e. borrow = not carry? If you do, the synthesis tool might optimise
'borrow' away and use carry throughout.
HTH., Syms.

 

[Symon]

Andy Botterill wrote:

Using verilog and ISE 10.1.

I add a reg to modify the design's behaviour. It works and it works
correctly. The change is intended to invert the carry logic for some
op-codes.

However synthesis , using XST , gives the following warning message.

WARNING:Xst:646 - Signal <borrow> is assigned but never used. This
unconnected signal will be trimmed during the optimization process.

Hi Andy,

Do you have a signal such as 'carry' which is the exact inverse of 'borrow'?
I.e. borrow = not carry? If you do, the synthesis tool might optimise
'borrow' away and use carry throughout.
HTH., Syms.

 

[TSIuser]

"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:484C29A9.6010000@gmail.com...

But Aldec seems to distribute the same vendor library-update in the form
of a download, up to a month later.

1. Aldec is not an oem for the major brands, however...
2. Compiling a library is not a big deal and ...

Ok, so there are no issues with the user re-compiling the Verilog/VHDL
simprim,
unisims, xilinxcorelib, from source? That's what I wanted to hear. I was
worried
that the vendor's libs used weird (non-standard) Verilog modeling, and that
it
might not work 'out of the box' with non-Modelsim simulators.

(My coworker told me this was a BIG problem with the whole Verilog
scene in general, back when the original Verilog-XL was king.)

3. If I am using synthesis, I don't need any libraries for simulation.
Use the source Luke.

?!? If your synthesizeable-RTL only uses generic statements (i.e. infered
FPGA-structures) , and not hand-instantiations, I can understand.
But what about when you instantiate specific I/O-cells, or a DCM?
Don't those have to come from the library?

And let's not forget Xilinx's Smartmodels for the TEMAC, Microblaze,
among other IP. (I hope the Smartmodel 10.1i installer has finally
gotten around to supporting Windows/Vista.)

 

[RCIngham]

Hi,

I have described a state machine running with an external pixel clock.
As I could see
on the oscilloscope the ScanDetect signal becomes high indicating that
the pixel clock
is stable. BUT the clock is not stable for some while after Scdt
becomes high. The clock
seems to tune after some us. (stable clock should have around 100MHz)
The clock is changing its frequency, high and low phases are
symmetrical.

If the FSM is running with that clock and if Scdt='1' is used to start
the FSM, can I trust
the state changes of the FSM ?

Thank you for your opinion.

Rgds
Andre

I would have thought that if the pixel clock frequency is lower than
standard before it locks, then you should be OK. Otherwise need to apply
the maximum clock frequency as constraint to P&R tool.

 

[RCIngham]

Hi,

I have described a state machine running with an external pixel clock.
As I could see
on the oscilloscope the ScanDetect signal becomes high indicating that
the pixel clock
is stable. BUT the clock is not stable for some while after Scdt
becomes high. The clock
seems to tune after some us. (stable clock should have around 100MHz)
The clock is changing its frequency, high and low phases are
symmetrical.

If the FSM is running with that clock and if Scdt='1' is used to start
the FSM, can I trust
the state changes of the FSM ?

Thank you for your opinion.

Rgds
Andre

I would have thought that if the pixel clock frequency is lower than
standard before it locks, then you should be OK. Otherwise need to apply
the maximum clock frequency as constraint to P&R tool.

 

[HT-Lab]

"Rob Gaddi" <rgaddi@technologyhighland.com> wrote in message
news:MuCdnaQ2cc-oUNPVnZ2dnUVZ_tyknZ2d@lmi.net...

Hey all --

So I've got a design, the very vaguest outlines of which are beginning to
gel. But one of the things that's becoming apparent is that it would
benefit from real clock rates somewhere between the obscene and the
unthinkable.

Throwing lots of money at the problem seems to get me to 500 MHz, yet more
can get me up to 550 MHz, but I could get a lot of other things to run
much more smoothly if I could get clock rates out into the 650 MHz
ballpark. That's for BRAMS and multipliers/DSP slices, not just the
flops.

You might want to talk to these guys, not sure if they have any real
silicon,

http://www.achronix.com/

Hans
www.ht-lab.com

 

[Joseph H Allen]

In article <g2os8s$7f97@cnn.xsj.xilinx.com>, austin <austin@xilinx.com> wrote:

The good news(?): I no longer manage the FPGA Lab (silicon verification
and characterization planning, testing, and coordination). That has
been re-organized, and its role expanded (which is all goodness).

Uh oh, so much for having accurate timing files for Virtex-6

I don't understand the reorganization either, other than in cynical excuse
for an executive bonus terms. XLNX stock price was a little low at the
beginning of this year, but not terribly low. It came back without this
action. The price has pretty much tracked ALTR so you can't say that X was
doing anything terribly wrong.

On the other hand, FPGA stock prices have been flat since the 2000 boom- I
don't see how a re-organization is going to change this. Maybe if Xilinx
entered a new market...

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Symon]

faza wrote:

Hai,

Can anyone explain how FIR filter implemented in real time
application....Wat is the role of software supporting the hardware???

regards,
faza



Dear faza,

You're starting to get slightly irritating now. This won't help you get
answers to your queries. A lot of folks on this newsgroup are willing and
able to help people just starting out in the field, but, like God, they like
to help those who help themselves.

Take your latest post.

Why don't you STW before posting? Googling for
FIR filter implemented in real time
gets nearly 10^6 hits.


It may also further your education to read this:-
http://catb.org/~esr/faqs/smart-questions.html

Please pay particular attention to the section:-
http://catb.org/~esr/faqs/smart-questions.html#writewell

Spelling 'what' as 'wat' apparently "makes you look like a semi-literate
boob" to save one entire keystroke, especially as you piss away the saving
by using three question marks when one will do just fine.

Finally, here are some feebie DSP books,
http://www.dspguru.com/info/books/online.htm

this site
http://www.xilinx.com/support/documentation/application_notes.htm
has at least two app notes about FIR filters in FPGAs,

and this site http://andraka.com/ is for when you become more experienced.

Now, be a good chap, and go do some reading.
HTH., Syms.

 

[Symon]

faza wrote:

Hai,

Can anyone explain how FIR filter implemented in real time
application....Wat is the role of software supporting the hardware???

regards,
faza



Dear faza,

You're starting to get slightly irritating now. This won't help you get
answers to your queries. A lot of folks on this newsgroup are willing and
able to help people just starting out in the field, but, like God, they like
to help those who help themselves.

Take your latest post.

Why don't you STW before posting? Googling for
FIR filter implemented in real time
gets nearly 10^6 hits.


It may also further your education to read this:-
http://catb.org/~esr/faqs/smart-questions.html

Please pay particular attention to the section:-
http://catb.org/~esr/faqs/smart-questions.html#writewell

Spelling 'what' as 'wat' apparently "makes you look like a semi-literate
boob" to save one entire keystroke, especially as you piss away the saving
by using three question marks when one will do just fine.

Finally, here are some feebie DSP books,
http://www.dspguru.com/info/books/online.htm

this site
http://www.xilinx.com/support/documentation/application_notes.htm
has at least two app notes about FIR filters in FPGAs,

and this site http://andraka.com/ is for when you become more experienced.

Now, be a good chap, and go do some reading.
HTH., Syms.

 

[RCIngham]

but i'm supposed to work until the 2nd layer i.e data link layer...so
i'll only be needing MAc addresses right?

Assuming that they haven't been mis-edited recently,
http://en.wikipedia.org/wiki/Address_Resolution_Protocol
and the articles it references should tell you what you need to know...

 

[Symon]

Alan Nishioka wrote:

On Jun 12, 8:14 am, ni <nbg2...@gmail.com> wrote:
I get the following error with chipscope analyzer whenever I do the
intialize chain.
ERROR: Socket Open Failed. localhost/127.0.0.1:50001
localhost
java.net.ConnectException: Connection refused
ERROR: Failed to detect cable.
Try to open a specific cable from the 'JTAG Chain' menu

IMPACT is able to initialize the chain successfully.

It looks like a network connection is failing. Are you sure you are
not being blocked by your firewall?

Alan Nishioka

Hi Alan,

I don't think that's it.
http://en.wikipedia.org/wiki/Localhost

Did the OP try turning his computer off and on again? ;-)

Cheers, Syms.

 

[Icky Thwacket]

<cpld.fpga.asic@gmail.com> wrote in message
news:80fc5390-d10b-43a9-89c7-0c2770a996b5@k13g2000hse.googlegroups.com...

Automotive Temperature +100 deg C+ FPGA's -- who's parts are available
from Distributor stock?

Am really interested in -40 to +125 deg C solutions that are
Automotive grade or Similar --

A quick trawl reveals Digikey have all these Altera parts in stock - I4
suffix - which are guaranteed -55C +125C parts

EP2S60F1020I4
EP2S60F1020I4N
EP2S60F484I4
EP2S60F672I4
EP2S90F1020I4
EP2S90F1508I4

probably a load more but can't be arsed to look.

Icky