EDK : FSL macros defined by Xilinx are wrong

[John Williams]

I wrote:

I wrote:

However, when placed in this slot the P160 MAC phy_rx_d<3> pin, defined
as 3.3V LVCMOS, connects to FPGA pin AD13 which is on the same IO bank
as most of the main board's DDR signals (2.5V SSTL) e.g.:

Any ideas on how I might get past this? I could fudge the IOSTD
constraints to force it to map, but intermixing 2.5V FPGA pins with 3.3V
signals seems like a bad idea.

Hmm, perhaps I should stop talking to myself so much.

Anyway, a very helpful Insight engineer has helped to resolve this one.
It's just a case of changing the IOSTD constraint to LVCMOS25, and
trusting the source termination resistors on the P160 module to
sufficiently reduce the 3.3V driving voltages down to the IO's
clamping/protection thresholds. This Xilinx answer says more:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=20492

Cheers,

John

 

[Ben Jones]

: Well, inserting registers changes your design in a fundamental way.
: Most circuits I can think of would just stop working if you added
: registers to them at random. Only you, the designer, know exactly
: how much pipelining it is legal to apply to a given part of your
: circuit. So I don't believe such a tool exists - certainly not in the
: general case.
This is very true, but there's no reason a designer couldn't specify a
bunch of signals (e.g. the data signal from a combinatorial multiply and
associated control signals) and some tool would add aribtrary (to a user
specified limit) stages of pipelining to all signals to meet timing, with
logic/register shuffling. This would only work the control and data flows
can be aribtrarily pipelined, but many ops can be described this way/

True, although I don't see much merit in doing it that way. In FPGAs, the
pipeline registers are essentially free (because they're there after every
LUT, even if you don't use them). So you don't get much advantage from
"just" meeting timing - if you have four clock cycles do do something in,
then you might as well take all four - who cares? You'll get better results
out of the tools that way, too.

Of course, if you *do* care about the latency of your operations and you
want to minimize it, then you're already thinking in enough depth about your
design that an automated tool would be unnecessary.

Cheers,

-Ben-

P.S. Whenever someone says "automated tool" I immediately envisage a smug
paperclip: "I see you're trying to close timing - would you like some help
with that?" This of course means that all my subsequent utterances on the
subject can be safely disregarded.

 

[Peter Sommerfeld]

Hi Davy,

No tool that I know of, but you can write code in such a way that the
pipelining is configurable. I've written a few blocks where I could
adjust the pipelining of the block by changing a "pipelining schedule",
which was just an array variable containing pipeline-able points in the
design. By changing this variable, I could change the amount of
pipelines, and therefore the amount of registers used and the fmax of
the design. This has worked pretty well for me for designs like binary
trees of arbitrary depth. At the top of the code I would have a
variable like:

pipeline_schedule(TREE_DEPTH-1 downto 0) := ( 0, 1, 1, 0, 1, 1 );

and further in the code where I would have, say a tree I would do
something like (this is not the actual code, just the idea here):

for i in 1 to TREE_DEPTH-1 generate
for j in 0 to LEAVES-1 generate
if (pipeline_schedule(i)==0) generate
-- just a level of logic
a(i)(j*2) <= max( a(i-1)(j), a(i-1)(j+1) );
end generate;
if (pipeline_schedule(i)==1) generate
-- create a pipeline stage
if clk='1' and clk'event
a(i) <= max( a(i-1)(j), a(i-1)(j+1) );
endif
endif
endgenerate;
endgenerate;

So whereever the variable pipeline_schedule has a 1, that level in the
tree would be pipelined. This works for a regular structure like a
tree. It would be more difficult to code something non-regular like a
complex control circuit with configurable pipelining. Anyways, this
method allowed me to balance an IP block between resource usage and
speed. You could extend the idea by automatically creating a schedule
if you knew how many levels of logic a certain fmax in a certain device
could be tolerated (I didnt' go this far; I created the schedule
empirically).

-- Pete

 

[damidar]

Thanks I have made as you have said... unfortunately nothing... not
work....

I have installed the last version of impact.....is the same...

 

[Gabor]

This is the "catch-all" error for impact when the JTAG loop doesn't
work. I've seen this problem when there was a break in the TDI to
TDO chain, especially when the break was in TDI at the programming
connector of the board to be programmed.

If your chain first shows up (parts correctly identified) and then
won't respond to any programming commands I would look at the TDI
line to the first device in the chain.

Also check that all devices in the chain have core and I/O power
and that PROGB and INITB lines are high (for FPGA's).

No version of impact will work if the chain is improperly connected.

Good Luck,
Gabor

damidar wrote:

Thanks I have made as you have said... unfortunately nothing... not
work....

I have installed the last version of impact.....is the same...

 

[Bruno]

thanks for the link!
Best Regards

"David Brown" <david.brown_spamnot@vertronix.com> escreveu na mensagem
news:OpudnbJkKolY-DLfRVn-vw@adelphia.com...

Did you try http://www.sierraic.com/ . I never purchased from them, but it
looks like they may have stock.

I found 34 of the XCR3384XL10TQ144C at this site.

D Brown

"Bruno" <bmscc@netcabo.pt> wrote in message
news:42af5b7d$0$32020$a729d347@news.telepac.pt...
Does anyone know where can I buy a Xilinx XCR3384XL tq144 CPLD?

Thanks in advance
Best Regards
Bruno

 

[Ben Jones]

Hi John,

the structure. It would be easier if the VHDL language standard was
modified to support "return generic values" that are computed during
component elaboration and returned as a compile time constant to the upper
level code that instantiates the component.

Yup, that gets said about once a week in this office.

Since VHDL doesn't let you do this, the only other solution I can think of
is to write functions in a package that perform the latency calculation at
the top level, and then pass the latency as a parameter to the lower level
components.

Well, the other possibility is to use flow control handshakes at each
pipeline
stage and put up with non-deterministic latency. That has its own problems,
of course - but I've found both approaches useful in certain contexts.

It's a pain to have to write the functions that calculate exactly where to
place the registers, since you have to take the latency as a given and
put it where it will do the most good.

As another poster indicated, if you have a bunch of sites where a register
could be placed, then it's a piece of cake to have an array of booleans
as a generic parameter to control the register placement. The problem
of finding optimal register placement can usually be solved by brute force:
write a script to implement the component using every possible vector with
N bits set, for every value of N you're interested in. In fact, you don't
even
need to do every possible vector (which is a binomial-type thing) because
you can easily prove that certain vectors will always be worse than other
vectors. This narrows the search space quite a bit (which matters if you're
talking about a 10-deep pipeline, but not so much if it's 3 or 4!).
Of course, you have to do this every time your design changes significantly;
but if your project is headed for a library which will be used many times
by many people, it shouldn't change (and the effort should be justified).

Having said all this, I'll close with the assertion that I can see the day
coming when it won't be just the logic that needs pipelining... Someday
we'll have to pipeline the routing too. Probably in the 45 nm node.

It's happening already. When you're designing for 300MHz plus, those
previously-innocuous net delays of 900ps are a massive chunk out of
your cycle budget. More than once I've ended up with a critical path
having no levels of logic...

Cheers,

-Ben-

P.S. I'm a Xilinx FAE, but writing this in my "off hours".

P.S. I'm a Xilinx design engineer, and I don't get "off hours".

 

[Symon]

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:f7o0b19ausim06im1kgts07e9a5abhjfar@4ax.com...

On Wed, 15 Jun 2005 09:49:36 -0700, "Symon" <symon_brewer@hotmail.com
wrote:


Here's one of our gadgets, built for the NIF laser...

http://www.highlandtechnology.com/DSS/V880DS.html

All the fast stuff is EclipsLite logic, pecl mode, and most of it is
single-ended except for a major clock which is a diff microstrip.

If you want low jitter, you have to know The Secret.

I guess you might need to know more than one Secret!! I see why you refer

all your stuff to the power plane, makes sense with the single ended stuff
in your logic family of choice. (ECL is referred to ground, so PECL is
referred to the power plane.) I tend to use exclusively diff pairs, LVDS,
PECL and CML, referred to ground. Works fine. I wonder if diff pairs work
slightly better referred to VCC? Hmmm.
I see the single digit jitter you mentioned is RMS, not pk-pk. That makes it
a little easier. Not that I'm not still very impressed!
Cheers, Syms.
p.s. As for Secrets, do you know where Syd Barrett lives?

 

[John Larkin]

On Fri, 17 Jun 2005 10:16:10 -0700, "Symon" <symon_brewer@hotmail.com>
wrote:

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:f7o0b19ausim06im1kgts07e9a5abhjfar@4ax.com...
On Wed, 15 Jun 2005 09:49:36 -0700, "Symon" <symon_brewer@hotmail.com
wrote:


Here's one of our gadgets, built for the NIF laser...

http://www.highlandtechnology.com/DSS/V880DS.html

All the fast stuff is EclipsLite logic, pecl mode, and most of it is
single-ended except for a major clock which is a diff microstrip.

If you want low jitter, you have to know The Secret.

I guess you might need to know more than one Secret!! I see why you refer
all your stuff to the power plane, makes sense with the single ended stuff
in your logic family of choice.

No, I refer my stuff to *any* plane that happens to be handy!

(ECL is referred to ground, so PECL is
referred to the power plane.) I tend to use exclusively diff pairs, LVDS,
PECL and CML, referred to ground. Works fine. I wonder if diff pairs work
slightly better referred to VCC? Hmmm.

Doubt it. Planes is planes.

I see the single digit jitter you mentioned is RMS, not pk-pk. That makes it
a little easier. Not that I'm not still very impressed!

Well, you can't actually measure p-p jitter.

Cheers, Syms.
p.s. As for Secrets, do you know where Syd Barrett lives?

Pink Floyd? Now *that* is a noise source!

John

 

[AMDyer@gmail.com]

The IDCODE is part of the jtag interface. You load an
idcode instruction in the jtag instruction register and
the part will connect it's idcode register into the jtag
data register chain. The s/w will then switch to shift
the data register out and can get a mfg., device, and
revision number from it.

If you have non-xilinx devices in your chain, make sure
you're driving their TRST/ (async tap reset) pin inactive.

Also it's been my experience in the past with impact that
you should just do the most straightforward path to
programming your parts - define the chain, set the config
file and program. Using any other 'features' of impact
is likely to get it confused.

 

[00andiweb.de]

Hi,

did you call the exception init function (XExc_init() ) which assigns the vectortable to the evpr register?

How does you c-code looks like?

 

[00andiweb.de]

Hi,

to add the c-code in sdram you need to store it in flash and build a booter that runs in the bram of the fpga to get the code out of the flash into the sdram and start it there. Do you have flash on your board?

The biggest "one" section with edk is 125 kb with several block rams. So you can store you whole project also in the bram of the fpga if you want to.

 

[00andiweb.de]

Hi,

do you have changed the modelsim.ini before you started the simulation?

 

[Austin Lesea]

Dave,

As can be expected, any FPGA's performance will vary based on the coding
style, the application, and the use of device specific features. We use
more than 100 designs from custoemrs to compare performance just for
that reason. We also evaluate each design carefully to make sure that
it is using the device resources appropriately (both for us, and our
competitors).

Xilinx claims the high road, both in superior performance, and superior
density (size). We claim more than that, actually...

A quick browse of the websites will provide you with more information
than you can read in one lifetime.

http://www.xilinx.com/products/virtex4/overview/performance.htm

is a good review of V4, which illustrate how we beat all other FPGAs in
EVERY category.

In fact, some categories there is no competition at all (ie 10 Gb/s
serial IOs, IBM PPC, and Ethernet MACs).

Quite a claim (at first glance), but consistent with Xilinx values, we
wouldn't make such a claim if it wasn't true, and backed by data,
evaluation boards, white papers, applications notes, and customer
testimonials.

Superior in EVERY way, Virtex 4.

Austin

Dave wrote:

Is the Xilinx Virtex 4 the fastest FPGA available in in-circuit
reprogrammable format?

Their data sheet claims 450MHz PPC and 500MHz DSP. The -12 speed grade of
the XC4VFX40 or 60 devcies sound like they won't be available until next
year, though.

I couldn't find definitive data in the Altera literature about the speed of
the Stratix II parts. Do these parts run at speeds approaching the Virtex 4
parts?

Does Lattice offer high-speed devices with built-in microprocessor, DSP, and
RAM support? It appears the EC family supports RAM at up to 200MHz.

Thanks.

Dave

 

[Duane Clark]

Nju Njoroge wrote:

Hi,

I'm using ModelSim SE 6.0a with ISE 7.1 (SP 2) and EDK (SP 1). I get
the following error with the PPC SmartModel.

# Loading work.ppc405_0_wrapper(structure)
# Loading C:/simlib/EDK_Lib/ppc405_v2_00_c/.ppc405_top(structure)
# Loading C:/simlib/unisim/.ppc405(ppc405_v)
# Loading C:/simlib/unisim/.ppc405_swift_bus(ppc405_swift_bus_v)
# Loading C:/simlib/unisim/.ppc405_swift(smartmodel)
# Loading c:\Modeltech_6.0a\win32/libsm.dll
# ** Error: Unable to read LMC SmartModel library file "** Fatal:
Foreign module requested halt.
# Time: 0 ps Iteration: 0 Instance:
/system/ppc405_0/ppc405_0/ppc405_i/ippc405_swift/ppc405_swift_inst
File: C:/Xilinx/smartmodel/nt/wrappers/mtivhdl/smartmodel_wrappers.vhd
# FATAL ERROR while loading design
# Error loading design
# Error: Error loading design

The VHDL file,
C:/Xilinx/smartmodel/nt/wrappers/mtivhdl/smartmodel_wrappers.vhd, is
where it is supposed to be and it looks legit when I open it. Also, I
recently upgraded from EDK 6.3, in which the SmartModel worked well. In
the upgrade, I followed the usual set of procedures
(http://www.xilinx.com/ise/embedded/ps_ug.pdf, page 120). Additionally,
all the simulations were re-compiled for the new versions of ISE and
EDK.

The smartmodel_wrappers.vhd does not appear to be your problem. The
error message claims the problem is with the "LMC" library. This would
probably be defined in your modelsim project file with a line like:

libswift = $LMC_HOME/lib/x86_linux.lib/libswift.so

Have you made sure that the combination of the environment variable and
the rest of the line points to the correct file?

 

[Mike Treseler]

ALuPin@web.de wrote:

Question: What if the signal in the slow clock domain should also be
one clock cycle high ?

Make a synchronizer and a
synchronous level change detector
on the fast clock.

-- Mike Treseler

 

[Duane Clark]

Vladislav Muravin wrote:

No, this is not the best method. Actually, this not a good method at all.

And since he didn't say why it is not a good method...

If your clk_rd and clk_wr are asynchronous (you don't actually mention
whether they are), then this method is guaranteed to corrupt the data.
Let's look at why.

You get a strobe_in and generate a fast_event and capture the data.
These signals travel to the registers that make up slow_clock_process,
each signal taking slightly different amounts of time due to routing.
Some of the fast_column signals go faster than fast_event, and some go
slower.

A clk_rd event happens to occur in the time between when fast_event has
arrived, but not all of the fast_column signals. If the clocks are truly
asynchronous, this is guaranteed to happen occasionally. The fast_event
causes slow_event to be captured, but only part of the slow data,
because not all the fast data has arrived yet.

On the next clk_wr, the fast process sees the slow_event flag and takes
away fast_event.

There are a number of possible solutions, but the best solution depends
to a large extent on the characteristics of when the fast data arrives,
and the relative clock speeds.

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11cnn43fdchjqc8@corp.supernews.com...
Hello group,

I am attempting to get data (column_in) from a fast
clock domain(clk_wr) to a slow clock domain(clk_rd).

Is this the best method?

fast_clock_process: process(clk_wr)
begin
if(clk_wr'event and clk_wr='1') then
if( fast_event='1' and slow_event='1') then
fast_event <= '0';
elsif( strobe_in='1' ) then
fast_event <= '1';
fast_column <= column_in;
end if;
end if;
end process;

slow_clock_process: process(clk_rd)
begin
if(clk_rd'event and clk_rd='1') then
slow_event <= '0';
if( fast_event='1' ) then
slow_event <='1';
slow_column <= fast_column;
end if;
end if;
end process;

 

[Bret Wade]

schellho wrote:

A question for the Xilinx guru's out there:

I am experimenting with the map -bp switch (map slice logic) in order
to make better use of device resources.

I am constraining my outputs with IOB = TRUE so that the mapper maps
them to IOB flops. When I use the -bp switch, however, I have an output
flop that is mapped to a block RAM despite the IOB constraint. The
clk-to-out timing specification is unreachable so the map fails with an
error message. I have tried applying the IOB constraint in the verilog
and in the UCF file.

Is there a way to force the mapper to ignore the -bp switch for certain
flops (other than creating and maintaining a mapping file), or am I
stuck with having to choose between IOB packed flops and block RAM
mapping?

I am using ISE6.1i.

Thanks in advance!

Mark

Hi Mark,

Try assigning the same BLKNM attribute to the FF and Pad, or a LOC
constraint on the FF if you already have an IO layout. These are both
harder constraints than IOB = TRUE and should work.

Another approach would be to specify the logic to be packed into BRAM using
the file based system documented in Answer Record 15888.

Regards,
Bret

 

[Peter Alfke]

NLP stands for Neuro-Linguistic Programming... (I had to google
that...)

IT is interesting that despite this frenzy about top speed, most users
always buy the (cheaper) slow speed grades... Makes you wonder what's
so important.

This reminds me of car advertising in Europe, where top speed used to
be the big issue.
"My fast 260 kmph BMW is better than your slow 255 kmph Mercedes !"
Nowadays, the distinction is more about important issues, like the
number of cupholders and foldable back seats...
Peter Alfke

 

[Joey]

<00andiweb.de> schrieb im Newsbeitrag news:ee8f784.0@webx.sUN8CHnE...

Hi,

did you call the exception init function (XExc_init() ) which assigns the
vectortable to the evpr register?

How does you c-code looks like?

Yes I did. Here is how it lokks like !!
XExc_Init();
// Register external interrupt handler
XExc_RegisterHandler(XEXC_ID_NON_CRITICAL_INT,
(XExceptionHandler)PLB_DECODER_Intr_DefaultHandler,(void
*)XPAR_PLB_DECODER_0_BASEADDR);
// Enable PPC non-critical interrupts
XExc_mEnableExceptions(XEXC_NON_CRITICAL);

enable_decoder_interrupts(XPAR_PLB_DECODER_0_BASEADDR);