EDK : FSL macros defined by Xilinx are wrong

[Newman]

Stephane,
I experienced a somewhat similar problem several months back, and it
too was with ise6.2. All the project files were on a remote
workstation for some type of corporate back-up thing. It was rumored
that it did on the fly file compression, had some type of disk file
caching system, any who knows what else. I tried putting all my files
on the local hard disk, and compiled from there. That solved my ISE
dependence compiling problem.

-Newman

 

[Bob Perlman]

On Thu, 17 Nov 2005 18:26:49 +0100, "Gunter Knittel"
<knittel@gris.uni-tuebingen.de> wrote:

Michael,

I don't know a good book, but a few web sites were helpful
for me, and may serve as a starting point.

http://www.ek.isy.liu.se/courses/tsek35/files2004/3.wires.pdf

http://www.bolton.ac.uk/mind/corep/sig-int/sig-int-1/lesson1.html#6

http://www.sp.se/electronics/RnD/reports/EMC/lccalc.pdf

At

http://www.sp.se/electronics/RnD/software/eng/LC-Calc.htm

you can find a tool for computing the mutual inductance and capacitance
matrices from conductor cross-sections. The matrices can be
used with PSpice to simulate crosstalk.
I experienced good agreement between the explicit formulas in the topmost
reference, the simulations, and later the measurements at the PCBs.
It appears that with the appropriate design style you can drastically reduce
XT - to a point where it is of no concern any more. I have a bus of
36 single-ended lines, each wire being 0.1mm (4mil) wide and
only 0.21mm apart from each neighbor (edge to edge),
running strictly parallel for >30cm (12"). Rise time is <1ns (ALVCH).
This appears to be a worst-case scenario, but XT never reaches critical
levels.
The important thing is to use a stripline configuration, in which inductive
and capacitive forward crosstalk cancel out. Backward crosstalk can be
controlled by series termination.

Hope this is of use for you,
cheers
Gunter

Thanks for the list of interesting links and documents.

I agree with what you said about using stripline to greatly reduce
forward crosstalk. But I don't agree that backward crosstalk can be
controlled with series termination, at least not in a way that's
generally useful. If you have two co-located drivers sending signals
along parallel traces to two co-located receivers somewhere else on
your board, series termination certainly helps control reflections on
both lines. But you'll still see the effects of backward crosstalk at
the receivers between time T and 3T, where T is the one-way line
delay. Give it a try in a SPICE coupled-line simulation.

By the way, the first edition of "High-Speed Digital Design" got this
wrong. Section 5.7.6 originally suggested that series termination
would improve crosstalk considerably; this has been amended in the
errata (http://www.sigcon.com/errataHSDD.htm). If Howard Johnson can
get it wrong, you know it's tricky.

Bob Perlman
Cambrian Design Works

 

[Mike Treseler]

tony.p.lee@gmail.com wrote:

It looks like Altera's Flex20 is the only FPGA with build in support
for CAM/TCAM.
But Altera doesn't seem to support CAM in the later Cyclone or Stratix.
Does anyone know why?

I expect that most customers didn't use it.

High density CAM seems like a valuable addition to the megasize FPGA
we have today, especially for network device.

The Altera CAM was inadequate for serious IP/IPv6 applications.
For less demanding applications, there are other ways
to cover a CAM function.


-- Mike Treseler

 

[Michael Chan]

Thanks for the replies everyone, I'll look into the suggested links and
books.

Cheers,

Michael.

"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
news:b6jpn11i2ef8l71loo42n2gn3lmlj7muei@4ax.com...

On Thu, 17 Nov 2005 17:19:17 +1000, "Michael Chan"
mchan@itee.uq.edu.au> wrote:

I'm looking for a good book that goes deeply into theory about
transmission
lines and crosstalk in high speed communications systems. If anyone has
any
good references, please let me know.

I have the book High-Speed Digital Design by Howard Johnson, which has
some
good stuff in it, but I'm looking for another reference which gives
detailed
attention to crosstalk. In particular, how crosstalk is modelled, and
methods for mitigating crosstalk.

Thanks in advance,

Michael.


I strongly recommend "Signal Integrity Simplified" by Eric Bogatin.
It's well-written, and manages to go into a lot of detail without
overwhelming the SI newcomer. And there's a 68-page chapter on
crosstalk.

Bob Perlman
Cambrian Design Works

 

[Andy Peters]

Chintan wrote:

architecture Behavioral of pioprocesses is
shared variable writingcontrolbits: std_logic := '0';
shared variable qualifiedread: std_logic := '0';
shared variable readingstatusbits: std_logic := '0';
shared variable readinginputbus: std_logic := '0';
shared variable readingdataregister: std_logic := '0';
signal CONTROL_REG: std_logic_vector (1 downto 0) := "00";
signal DATA_REG: std_logic_vector (7 downto 0) := "00000000";
signal STATUS_REG: std_logic_vector (2 downto 0) := "000";

yikes -- what's with all of the shared variables?

-a

 

[Brad Smallridge]

-- Creates an ERRORlace:645 if UCF file LOCs pins to non clock inputs
-- cam1_xclk_ibufd_inst : IBUFDS
-- port map (
-- O => cam1_xclk, -- to DCM input
-- I => gpio_exp_hdr2(7),
-- IB => gpio_exp_hdr2(6) );

-- This code didn't help the ERRORlace:645 / WARNINGlace:644 problem
-- Does improve the route if one moves the pins to a clock input

-- cam1_xclk_ibufgds_inst : IBUFGDS
-- generic map (
-- -- DIFF_TERM => "FALSE", -- Differential Termination (Virtex-4 only)
-- -- Above line created a TYPE error
-- -- Language Template differs from v4ldl libraries guide.
-- -- IBUF_DELAY_VALUE => "0",
-- -- Specify the amount of added input delay for buffer,
-- -- "0"-"16" (Spartan-3E only)
-- IOSTANDARD => "DEFAULT")
-- port map (
-- O => cam1_xclk,
-- I => gpio_exp_hdr2(7),
-- IB => gpio_exp_hdr2(6));

-- This code does not get rid of WARNINGlace:644 but
-- does improve the appearance of the internal clock route
-- even though the UCF file has the pins LOC to non clock inputs

cam1_xclk_ibufd_inst : IBUFDS
port map (
O => cam1_xclk_intermediate,
I => gpio_exp_hdr2(7),
IB => gpio_exp_hdr2(6) );

cam1_xclk_bufg : BUFG
port map (
O => cam1_xclk, -- to DCM input
I => cam1_xclk_intermediate );

Brad Smallridge
aivision.com

 

[Adrian Knoth]

Eric Smith <eric@brouhaha.com> wrote:

BTW: backticks are deprecated, use $() instead
Deprecated? Why bother?

POSIX? Don't know. I think is was ok in the 90ties, but I wouldn't
use them in new scripts


--
mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver

Nicht alles was hinkt, ist ein Vergleich.

 

[Gunter Knittel]

Bob,

I'd still say that series termination reduces crosstalk since none
of the backward crosstalk of the forward signal gets reflected
towards the receiver. So one more contribution is removed.
Other than that, I think you're right, thanks for pointing that out!
We will see backward crosstalk from the reflected signal -
except of course there is some kind of termination at the receiver.

I guess I was too generous in my previous statement since in my
configuration, backward crosstalk appears to be no big problem at
all. According to my simulations, two aggressor lines driven to 3.3V
couple into a victim line in the middle no more than 100mV at the
receiver. On the scope I see a little more than that, but still well below
the threshold.

Gunter


"Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message
news:gfjpn1hb5dr5fsvcbl15utpjjgm9ticrh7@4ax.com...

On Thu, 17 Nov 2005 18:26:49 +0100, "Gunter Knittel"
knittel@gris.uni-tuebingen.de> wrote:

Michael,

I don't know a good book, but a few web sites were helpful
for me, and may serve as a starting point.

http://www.ek.isy.liu.se/courses/tsek35/files2004/3.wires.pdf

http://www.bolton.ac.uk/mind/corep/sig-int/sig-int-1/lesson1.html#6

http://www.sp.se/electronics/RnD/reports/EMC/lccalc.pdf

At

http://www.sp.se/electronics/RnD/software/eng/LC-Calc.htm

you can find a tool for computing the mutual inductance and capacitance
matrices from conductor cross-sections. The matrices can be
used with PSpice to simulate crosstalk.
I experienced good agreement between the explicit formulas in the topmost
reference, the simulations, and later the measurements at the PCBs.
It appears that with the appropriate design style you can drastically
reduce
XT - to a point where it is of no concern any more. I have a bus of
36 single-ended lines, each wire being 0.1mm (4mil) wide and
only 0.21mm apart from each neighbor (edge to edge),
running strictly parallel for >30cm (12"). Rise time is <1ns (ALVCH).
This appears to be a worst-case scenario, but XT never reaches critical
levels.
The important thing is to use a stripline configuration, in which
inductive
and capacitive forward crosstalk cancel out. Backward crosstalk can be
controlled by series termination.

Hope this is of use for you,
cheers
Gunter

Thanks for the list of interesting links and documents.

I agree with what you said about using stripline to greatly reduce
forward crosstalk. But I don't agree that backward crosstalk can be
controlled with series termination, at least not in a way that's
generally useful. If you have two co-located drivers sending signals
along parallel traces to two co-located receivers somewhere else on
your board, series termination certainly helps control reflections on
both lines. But you'll still see the effects of backward crosstalk at
the receivers between time T and 3T, where T is the one-way line
delay. Give it a try in a SPICE coupled-line simulation.

By the way, the first edition of "High-Speed Digital Design" got this
wrong. Section 5.7.6 originally suggested that series termination
would improve crosstalk considerably; this has been amended in the
errata (http://www.sigcon.com/errataHSDD.htm). If Howard Johnson can
get it wrong, you know it's tricky.

Bob Perlman
Cambrian Design Works

 

[Brad Smallridge]

-- Creates an ERRORlace:645 if UCF file LOCs pins to non clock inputs
-- cam1_xclk_ibufd_inst : IBUFDS
-- port map (
-- O => cam1_xclk, -- to DCM input
-- I => gpio_exp_hdr2(7),
-- IB => gpio_exp_hdr2(6) );

-- This code didn't help the ERRORlace:645 / WARNINGlace:644 problem
-- Does improve the route if one moves the pins to a clock input

-- cam1_xclk_ibufgds_inst : IBUFGDS
-- generic map (
-- -- DIFF_TERM => "FALSE", -- Differential Termination (Virtex-4 only)
-- -- Above line created a TYPE error
-- -- Language Template differs from v4ldl libraries guide.
-- -- IBUF_DELAY_VALUE => "0",
-- -- Specify the amount of added input delay for buffer,
-- -- "0"-"16" (Spartan-3E only)
-- IOSTANDARD => "DEFAULT")
-- port map (
-- O => cam1_xclk,
-- I => gpio_exp_hdr2(7),
-- IB => gpio_exp_hdr2(6));

-- This code does not get rid of WARNINGlace:644 but
-- does improve the appearance of the internal clock route
-- even though the UCF file has the pins LOC to non clock inputs

cam1_xclk_ibufd_inst : IBUFDS
port map (
O => cam1_xclk_intermediate,
I => gpio_exp_hdr2(7),
IB => gpio_exp_hdr2(6) );

cam1_xclk_bufg : BUFG
port map (
O => cam1_xclk, -- to DCM input
I => cam1_xclk_intermediate );

Brad Smallridge
aivision.com

 

[gallen]

Austin, I have to disagree with you about most designs being done with
fpgas and there being loads of jobs in the market. I fairly recently
graduated from school with a computer engineering degree. I did a lot
of FPGA work while I was in school using both Xilinx and Altera
platform (as for the X vs. A debate, I'm agnostic, I find Xilinx's
tools to be more complete, but I find Altera's GUI to be nicer).
Despite doing all of that FPGA work I did not find a single job having
anything to do with FPGAs. However, I worked for an ASIC company that
was not on your list and now I work for a different ASIC company. I
get the impression that ASICs are still very popular despite their
rising NRE costs.

All that said, I do recommend looking at all the FPGA stuff you can.
Regardless of whether you go into ASICs or FPGAs in your career, FPGA
development will give you a *GREAT* background. I might even go so far
as to say that FPGA development will give you a better modern digital
design background that most of the old-timer engineers have.

My experience has been that FPGAs teach all of the fundamentals:
* basic logic design
* static timing
* hand optimization to meet timing
A couple of things are skipped like:
* electromigration
* cross-talk
* voltage-domain crossing

But really FPGAs offer most of what you need. The really big thing
that they do that many of the "old-timers" don't get is they force you
to reduce the number of clock domains you have. FPGAs have a very
limited number of global clock nets. As a result you learn that it's
best to not generate a clock for every single flip flop that's driven
or to put HUGE amounts of logic in a clock net or to do loads of async
design. This is a great thing to get used to since modern ASIC and
FPGA flows do not adapt well to this.

I might also add that when you're looking at internships and first jobs
that it's best not to expect to do exactly what you want. You can ask
around to all of your profs to see if they have contacts, but my
experience has been that it is generally not the case. My profs seemed
to like to avoid FPGAs like the plague and generally thought that
digital design was for the weak (or something since they did a pretty
lousy job of teaching it in my opinion).

Good luck. Also, don't be afraid to apply for jobs that you're
under-qualified for. A lot of companies put up requirements that are
completely outlandish hoping for a miracle, but expecting much less.
If a job says 5 years experience required. Go ahead. Apply for it!

-Arlen

 

[Subroto Datta]

To get a good idea of the type of applications that Cyclone II /Cyclone
devices are used in check the following link:

http://www.altera.com/corporate/cust_successes/customer_showcase/view_product/csh-vproduct-cyclone.jsp

The use of these devices in an application is only limited by your
imagination. Remember you can have your own NiosII processor running on
these chips, to allow you greater flexibility and creativity. In a student
competition sponsored by Altera, one of the winners implemented a biometric
system running on a Cyclone chip using the UP3 board.

Happy experimentation,
Subroto Datta
Altera Corp.

"badgrant" <badgrant@yahoo-dot-com.no-spam.invalid> wrote in message
news:V5idnQ62EdUrBuDeRVn_vA@giganews.com...

hi, i'm grant, studying computer engineering in university of ottawa.
i'm using altera cyclone II on up3 board with quartus II enviorment.
how is it? is it leading in industry? what kind of job can i get when
i'm done.

guys, forgive me if i have tons of questions, coz i do care about my
career while i know nothing about it right now.

 

[Raymund Hofmann]

"JustJohn" <john.l.smith@titan.com> schrieb im Newsbeitrag
news:1132397821.560864.109950@g49g2000cwa.googlegroups.com...

On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:

"I use exactly this template of three top procedures in every new
design entity:

begin -- process template
if reset = '1' then
init_all_regs; -- no port init required
elsif rising_edge(clock) then
update_process_regs;
end if;
update_output_ports; -- wires ok for reset or clk
end process template;
"

Do you want to take the fun out of the world of electronic design ?

This is only the most recent example, and seeing this asynchronous
reset code over and over again is starting to worry me, particulary
considering that some FPGA's may be in critical environments, where
cleanly coming out of reset is vital.

Our evolution is try and error. Do you want to hinder our evolution ?
Do you want to take the exitement out of our lives ?

And Frankly, every modern (since the Wintel revolution) user of any
electronic device will "reboot" it until it works without worrying. I've
already adapted this behaviour subconsciously.
I also experience a much higher rate of failure during operation of
electronic devices.

Raymund Hofmann

 

JustJohn wrote:

"The tools do not automatically analyze asynchronous set/reset paths."
(I assume tools means Map/Place/Route)

This bears repeating.
"The tools do not automatically analyze asynchronous set/reset paths."

You can turn this on the UCF. Every UCF I have ever written has
contained the lines:

# magic incantation to make the tools trace timing through reset paths
ENABLE= reg_sr_q;


Regards,
Allan

 

[gallen]

I suppose I should mention that consumer level products are often where
the ASICs lie. In situations where there may only be 10s, 100s or
1000s of parts, FPGAs may be very common. My work currently gets
manufactured in the 100s of millions and it contains a large analog
block. It just simply isn't suited for FPGA.

I could see FPGAs being big in high end space (I think Cisco uses FPGAs
for its backbone class routers). I could see them in government space.
I could see them in prototypes (heck, our architects use them for
accellerating matlab tests). I just can't see them making much inroads
into high volume consumer space.

The important detail to be taken from this though is that ASICs are
still very alive for very high volume work as well as high speed
(multi-GHz) and analog.

Best of luck to all of those students out there hunting. There is an
amazing amout of interesting work to be done. Also, pay attention in
your signal processing classes. That is some really important stuff.
-Arlen

 

[Mike Treseler]

Hal Murray wrote:

Is that good enough?

It has been in many cases.

Don't you also need the prop time on that low-skew path
to be short enough relative to your clock cycle time so
that you know when it gets to your FFs?

For the trailing edge, yes.
On the board, a zero delay clock buffer
and careful distribution to all devices does
the trick. On the fpga I just have to make
sure the reset node gets one of the global nets.

Last I checked, the global reset on most Xilinx parts
was too slow to be useful in that context.

Yes. I don't use anyone's the built-in reset.

I thought that consensus here was to use the global
reset hardware to (asynchronously) force your state
machines into a known state and then use a local
FF that has been synchronized to get out of that state.

I don't think I'm contradicting that idea.
The asynch reset gives you a starting
point for simulation. After this, well-designed
control logic will use an idle state for
specific synchronous initialization.

-- Mike Treseler

 

[JustJohn]

(Back from my walk...)

Hal wrote:

I thought that consensus here was to use the global
reset hardware to (asynchronously) force your state
machines into a known state and then use a local
FF that has been synchronized to get out of that state.

Aaahhh, thanks Hal, _very_ nicely put, succinct and clear. (It's been a
while since those discussions, I turned 50 last month, and have been
working in the wonderful world of M$ GUI design lately, so forgive me
for forgetting).

Integrating everyone's good words with Mike's generic process template
and my desire for an entity local reset into pseudo VHDL:

process (clock, gsrout) begin
if gsrout = '1' then
init_all_regs; -- Every darn one of them
init_state_regs; -- To a 'dormant' reset state
elsif RISING_EDGE(clock) then
if reset = '1' then
init_some_regs; -- Only ones really that need it,
-- both to reduce routing req's,
-- and because it may be useful
-- to keep some values across
-- a reset event
init_state_regs2; -- To an 'awake' reset state
else -- No enable form
[elsif enable = '1' then] -- Using enable form
run_reg_logic; -- And they're off to the races
run_state_logic; -- (oops, bad word, no races here!)
end if; end if;
end process;

Signal gsrout comes from the Xilinx 'STARTBUF_arch' primitive, so that
the async device clear does not take FF pins or routing. (Mike may not
like this vendor specific stuff, see my parting question)

Googling back to June reveals a 'roller' (http://tinyurl.com/ajvtw) who
asked about _not_ using this format. Nobody answered then, but after
going through this exercise, I would say this is a fairly solid
template, don't use it at your own peril.

Ok, I'm done, except for one last question... does Altera have a
similar GSR function? (Please pardon my laziness)

Thanks all,

John

 

[JustJohn]

huangjie wrote:

Because the ASIC has too many interface therefor too many clk and some of
the clk does not route to fpga's dedicated clk pin ,for eg, pci clk does route to an > normal I/O pin.

How fast are the clocks that are not on the dedicated clock pins? If
they are slow enough, you can sample them with a faster clock to
generate an enable signal on the edge you want, and run your internal
logic on the faster clock using that enable. The code would be
different for your FPGA vs. your ASIC though:

FPGA:
process (fastclk)
begin
if RISING_EDGE(fastclk) then
if enable = '1' then
...

ASIC:
process (pinclk)
begin
if RISING_EDGE(pinclk) then
...

(It's for situations like this that I wish VHDL had a pre-processor
like C)
It might be tricky at PCI speeds, but if this is a prototyping system,
you may be able to slow down your PCI clock.

Regards,
John

 

Hi,
That would be more of a Q to your synthesis tool (which I'm not
overly familiar with). However Modelsim has a nice "virtual bus"
command/feature to do exactly what you wanted - check their doc.

HTH
Ajeetha
www.noveldv.com

 

[Gabor]

Fred wrote:

"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:dlskc7$610$1@news.datemas.de...
On a sunny day (Mon, 21 Nov 2005 12:48:13 -0000) it happened "Fred"
fred@nowhere.com> wrote in <4381c20e$0$23287$db0fefd9@news.zen.co.uk>:

I find it frustrating that there is no way or telling if a compilation has
ended or not. I can't find any feature in ISE which makes a sound when
it's
finished. I am aware that some might find this an annoying feature but
would save me periodically checking to see if it's finished or come to an
end early due to a mistake.

Any ideas?
I'd think that hanging a themocouple with level detector on the processor,
or heat exhaust, was a nice lunch 'time project ;-)

In Linux you could use grep or awk on the output of 'top':

CPU states: 0.5% user, 2.7% system, 15.4% nice, 81.1% idle

look for > X percentage idle, and use keyboard beep:
echo -e "\a"

....


A utility to see if a file had been modified would be a possible method.

I usually start the build by double-clicking "Generate PROM, ACE, or
JTAG File"
which will pop up an iMPACT window when finished. Sound would be
nicer, though
because I'm usually typing something when the window pops up and takes
over
the focus...

 

[Sean Durkin]

Mike Harrison wrote:

I would also find this very useful - I was wondering if there was
maybe a way to insert an extra program to go 'ping' into the list of
executables that are run as part of the build process. I'd also
really like to see an option to download to device on successful
compilation.
You could do the entire flow with "make" from the command line. There

you can
add a command to issue a beep at the end, or send email, or send a
Winpopup message, or whatever you like. The part about downloading to
the device wouldn't be a problem either. And the makefile you'll only
have to do once, that usually stays the same, since only the list of
source files and the project name change.

cu,
Sean