EDK : FSL macros defined by Xilinx are wrong

Glen,

Please check if you are getting the following message:

Warning (10040): Verilog HDL or VHDL arithmetic warning at <location>:
loss of carry in addition or borrow in subtraction

If so, then this is a linting message that points out a potential
design mistake. It's a related, but nevertheless distinct issue from
simple truncation. If you get the truncation warning, you may be using
a much older version of the software that didn't distinguish loss of
carry from generic value truncation according to Verilog expression
sizing rules. If you want you could mail the qar file for your project
to me and can confirm.


Hope this helps,
Subroto Datta
Altera Corp.
 
Have you considered XCL as the interface?

"Xilinx CacheLink (XCL) is a high performance solution for external
memory
accesses." http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf

Paul

Zara wrote:
Hello all,

I am designing a communications board based on a microblaze implementes
on a spartan 3 400.

I have 512kx32 external synchronous RAM, and I am trying to connect it
to the microblaze by the LMB, both to data and instruction sides, so I
have to multiplex both buses, giving priority to instruction bus. All
this is easy and I have done it. Well, it seemed easy.

When I test the external memorys, everything goes fine except when the
interruption to MB activates one cycle before a memory read, so thtat
INTERRUPT_TAKEN acknowledges the interrupt some 4-5 cycles after that
(it is not a variable amount, it is fixed biut I have closed the
chipscope window before writing this).

Now at last, the *problem* or, as the C++ experts say the Really Bad
Thing TM. Whenever this interlave of interrupt and memory fetch happens,
register R14 does not save PC, but gets the value 0x00000000, thus
causing a reset after the interrupt attention routine.

By the way, all interrupt code and data lies within BRAM, and the
external RAM cycle presents no anomalies, it end correctly.

Has anyone any information to guide me to solution, or will I be forced
to connect a fast synchronous RAM to OPB, thus working at half speed?

Thanks to all

Juan A. Zaratiegui
 
sanjay.gajendra@gmail.com wrote:

You need to use multi-cycle contraints!

Regards,
Mark
 
Paul Hartke wrote:

Have you considered XCL as the interface?

"Xilinx CacheLink (XCL) is a high performance solution for external
memory
accesses." http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf



No; but I´ll give it a try. I Just thought that multiplexing two chache
links shoudl be far more difficult than multiplexing two LMB interfaces,
but that was only un undocumented thought. I will document myself now.

Thank you very much,

Zara
 
Austin wrote:
It really is 5pF across 100 ohms
As presently documented in your datasheets and IBIS files, it's
really two 10 pFs in shunt to ground across a 100 ohm +/-20% R.

It may appeal to your inner marketeer to call it 5 pF, but that
won't make your parts work any better.

If you're going to continue to 'correct' folks who quote your
own documentation, at least have the technical honesty to point
out that modeling two shunt C's as an across-the-pair 1/2 C is
ONLY valid if the input signal is perfectly differential.

Here's to hoping that when you eventually publish S3E IBIS and
SSO info, those slimmed-down DCI-less I/O buffers have a lower C.
( And I'd still love to see some of the smaller S3E parts appear
in a ground-paddle VQFP or QFN package )

As well, "they" use an external 100 ohms for all their simulations,
where we recommend use of the internal 100 ohms for all high speed
interfaces (really makes things look worse due to the stub).
Perhaps you should review your own documentation before throwing
stones at others.

The last time we went round on this, you pointed to the ML450 V4
evaluation board as a shining example of SI design.

If you look at the ML450 schematic, BOM, and board layout, you'll
notice that the HyperTransport input lines are terminated using
external 100 ohm resistors, with stub lengths of about half an inch.

Maybe this was done because you can't meet the HyperTransport +/- 10%
terminator R spec with the _DT terminators, but I'd wager that the
internal R's would work better than those big stubs, especially with
the non-compliant Cin values of your HyperTransport inputs.

I didn't spot any supporting IBIS sims for the ML450 layout anywhere;
perhaps you could publish some 500 MT/s and 1 GT/s simulations in
the user guide, using a fast HyperTransport compliant driver, with
waveforms plotted both at the internal FPGA Rx and at a HyperTransport
bus probe connector on the driving board :)

From HyperTransport 2.0:

internal terminator Rt : 100 ohm +/- 10%

single ended Cin (400-800 MT/s) : 5 pF
single ended Cin (1-2 GT/s) : 2 pF

single ended Cout (400-800 MT/s) : 5 pF
single ended Cout (1-2 GT/s) : 3 pF

Any mention of HyperTransport in your datsheets, app notes, and
user guides should be appropriately footnoted as non-compliant.


Brian
 
Do you think the A version works? I can't get an SST part from Digikey,
my only source, which means I'm out of luck :(

I just can't seem to grasp that one of these parts costs $17....
 
In Verilog, I do it by defining all variables as signed. Then it's
automatic.

reg [7:0] p1;
reg [7:0] p2
wire signed [8:0] p1s;
wire signed [8:0] p2s;
wire signed [8:0] diff;

assign p1s = p1;
assign p2s = p2;
assign diff = p1s - p2s;

Notice that I made all variables 9-bits to ensure that values up to
255 will be treated as positive numbers and so that the result can
represent the full range of -255 to +255.

Marko


On Wed, 7 Sep 2005 06:21:37 +0200, "news.green.ch" <rb@freesurf.ch>
wrote:

Hi
I'am a newbe, and know how to add unsigned numbers in Verilog HDL, but how
to define a signed number?
I've the following situation:

reg [7..0] p1 //(is an unsigned value from AD converter) 0..255
reg [7..0] p2 // is the unsigned value that we should have 0..255

now I want to substract p1-p2, to have the differenz, to correct the error
reg[7..0] diff //should be a signed value

how do I define this in Verilog HDL


best regards remo



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
I have no idea which of these parts might work. The SST parts are pin
compatible but have different IDs. They probably cannot program from
quartus but they might read OK.

Looking at the *.pof for a Cyclone configured to load from an EPCS4, the
string EPCS4 is included at the start.

I'm not sure of why I think this, but I've an idea that the devices check
the device ID at the start of config, although this might be wrong.

If this is the case you'd have to use a device with the same ID.


Nial.



-------------------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk
 
vssumesh wrote:
I wont be able to do the first two methods as it will disable all the
output pins.
I know that the third method is reasonable. But i am unable to explain
the behaviour.
1. I deleted all the connection to the 'A' and 'B' bus from the FPGA.
But still some bits in the bus 'B' was missing. Then i connected the
FPGA to the bus 'B' and assigned input status. Then bus 'B' started
working but bus 'A' reported errors. How can it be possible.
The same thing happend when i assigned input to both buses. If i go for
bus 'B' bus 'A' gets corrupted and vice versa.
If i assign input to both the buses still bus 'A' reported errors.
And for your question i dleted all the driving of bus 'A' and 'B' from
the RTL.
Sumesh
The problem which you report remembers me of an odd behavior I
encountered with a previous design. It turned out that the top-level
port mapping (VHDL design flow) didn't match the UCF file (my mistake).
More precisely, I had a couple IOs in the port mapping which weren't
declared in the UCF file (running PACE and uncheking the "Allowing
Unmatched LOC Constraints" implementation option revealed the error).

The SW tools (AFAIR) connected these undeclared IOs into the first
unused physical pad it found. It goes without saying that the design
was then acting a bit strangely ;)
 
Hello Vladislav,

Thanks for the reply.

Yes i also think my implementation is correct. I have ported it to FPGA
and i am facing the same problem.
I am able to read the internal register (reset value) in only slave
interface but if i trisatate the bus for
interfacing the master and slave i reading all zeros. After probing the
internal signal through chipscope
i came to know that all the signal which i am tristating is being
connected to ground.
I am using synplify for synthesis and then EDF being implemented on
ISE.

Thanks and regards
williams
 
Folks,

The 25P10A from ST do work fine.

Looking at the *.pof for a Cyclone configured to load from an EPCS4, the
string EPCS4 is included at the start.
Yes the *.pof knows what is the target device.

I'm not sure of why I think this, but I've an idea that the devices check
the device ID at the start of config, although this might be wrong.
That info on the *.pof file is for the programmer soft-module to know how to
program, and that doesn't go into the device.

If this is the case you'd have to use a device with the same ID.
The Cyclone device check the device ID to know how much data it
may have to load, just that... I think.

I can't tell what ID's are recognized by the Cyclone load engine... but
at least the ones corresponding to the EPCS1 and EPCS4 are for sure.


The bottom line is still, ST25P10A has the exact same ID as the EPCS1 and
quartus II
still fails to load them.
However is a fact that once programmed (by other means) Cyclone devices
do read them without trouble.


Luis C.



"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message
news:4321c8d9$0$21184$db0fefd9@news.zen.co.uk...
I have no idea which of these parts might work. The SST parts are pin
compatible but have different IDs. They probably cannot program from
quartus but they might read OK.


Looking at the *.pof for a Cyclone configured to load from an EPCS4, the
string EPCS4 is included at the start.

I'm not sure of why I think this, but I've an idea that the devices check
the device ID at the start of config, although this might be wrong.

If this is the case you'd have to use a device with the same ID.


Nial.



-------------------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk
 
Please go through the topic "Disconnect the FPGA I/O pads from the
outside world". I think our problem is similar.
 
Bob Myers wrote:

I'm used to having an external reset line feed one of the pins, that
could be
specified to Leonardo 4.22 as the global_sr signal.
Actually, Leo will find the external reset and put
it on a global line for you if you use a standard
synchronous template.

When I try to read in the design, I get told by Leonardo that the GSR
net name
that I'm using does not have a source --> looking at the schematic
viewer, I
find that all of the GSR nets get grounded.
Use of the GSR in your design description
is optional and the Leo default
is to not use it. I think this is a good thing
as it makes your design more portable and
easier to simulate.

Consider using an external pin for reset.

-- Mike Treseler
 
Hi ,
Do u have Xilinx EDK 6.2 tools, in case u have them then , if u
go to /hw/XilinxReferenceDesigns/pcores/opb_core_msp0_v1_00_b/ , thats
nothing but a OPB Bus Master design with Write capability. The only
catch is that it uses a very old version of IPIF. If you are ok with
that then you can go ahead and use it.
In case u dont have EDK 6.2 , then just send me an e-mail and I
can tar the file and send it to you ..

--
Parag Beeraka
 
stud_lang_jap@yahoo.com wrote:
FATAL_ERROR:Xst:portability/export/Port_Main.h:127:1.13 - This
application has discovered an exceptional condition from which it
cannot recover.
I would start at having a closer look at the synthesis report file. Most
of the time when something like that happens there are earlier error or
warning messages that could hint at what's really wrong. You can open
the synthesis report either in ISE (but there the function to display it
usually only works when there are no fatal erros) or by opening the
*.syr-file ISE creates in your project directory with a text editor.

Maybe there are some clues there. Otherwise, there's really not much you
can do... FATAL_ERRORS are supossed to only show up when there's
something really terribly wrong somewhere... Mostly, bugs in the software...

Plus, have you looked at Xilinx Answer Records on
http://support.xilinx.com ? This looks similar to your problem, although
the ISE version doesn't match:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17481

cu,
Sean
 
The SDF is applied to the backannotated Verilog.
Thanks for your indication about GTS, but it seems that your response
has been stopped by something / someone, you are going to...?
Thanks for any help
Gio
 
What about signal integrity? impedance matching?

Aurash

Hiding in Plain Sight wrote:

On Mon, 12 Sep 2005 10:16:35 +0100, Jon Schneider wrote:



I've got my design talking to some (Kingston) KVR133X64/1G SDRAM
modules and running at only 66MHz, doing some simple testing (the
data=address or maybe data={address,address}) and have found some funnies.

There are a few dozen single bit errors. There are also several
locations that come back with some F digits (as if the cells just
don't exist). Also they are mid-burst as much as not which indicates
it isn't a timing problem.

I have done testing on different FPGAs with different SDRAM modules
and the errors definitely go with the modules and are quite
repeatable.

I have checked the refresh timing and it's good.

Is Kingston SDRAM really that bad ? The fact they are made of
repainted Infineon chips such that you can't read the original part
number makes me suspicious that these might not be the real
thing. They claim 100% testing but I wonder what they do with modules
tested as bad. Is it because the FPGA can keep memory busy in a way a
processor can't ? Should I speed up the refresh ? We intend to try
some Micron parts anyway.

Jon



I'd suspect your design before I'd suspect the modules especially if it's
more then one module that's failing. Have you simulated the design using
the Micron DRAM models? The Micron models do a very good job of checking
that you've met all of the timing requirements. DRAMs have a lot timing
requirements, not just set up and hold and refresh intervals, but things
like precharge times, RAS to RAS times on the same bank, ...

--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/

phone: 353 01 4032639
fax: 353 01 4640324
 
"Giox" <giovanniparodi79@yahoo.it> wrote:

The SDF is applied to the backannotated Verilog.
The pre-route Verilog? Or the post-route Verilog?


--
Phil Hays to reply solve: phil_hays at not(coldmail) dot com
If not cold then hot
 
The note regarding JTAG signal coupling is in the MAX II Errata sheet
and applies only to the EPM1270 ES devices in the T144 package. The
details of that are explained in the errata. This TDO/TCK coupling was
corrected in the production EPM1270 devices (non-ES). You should check
errata sheet to make sure this isn't related to your problem.

The security bit does not prevent the device from being re-programmed
nor does it prevent the part from being ID'd. A device with security
bit set cannot be stand alone verified nor can it be examined/readback.
The readback data on a secured MAX II part will read back as if the
device were blank. If security bit is set, you can still re-program
the device with a new design/POF. I tried it on a couple EPM1270 MAX
II dev kits and it works okay.


-Joe D
 

Welcome to EDABoard.com

Sponsor

Back
Top