EDK : FSL macros defined by Xilinx are wrong

[Brannon]

You have a good point. I should have clarified. The subtraction only
uses two inputs per LUT. The same is the case with what you're
proposing for the compare. It seems to me you could double the density
by adding an extra switch bit to the MUXCY because the LUT already
supports four inputs.

 

[Joseph]

Well, I got over this problem. Now if anyone knows how to use XMD to
get xilmfs files/filesystems back out of the RAM after my embedded
program has run, I would love to hear about it.

Joey

 

[c d saunter]

CMOS (manusha@millenniumit.com) wrote:
: here we go again...showing off stupidity....

Yay veriily, showing off with an understanding of capitalisation no less,
and even providing an on topic response to someone who's heading for my
usenet killfile...

---

 

[Gabor]

Brannon wrote:

You have a good point. I should have clarified. The subtraction only
uses two inputs per LUT. The same is the case with what you're
proposing for the compare. It seems to me you could double the density
by adding an extra switch bit to the MUXCY because the LUT already
supports four inputs.

Might be good for compare, but since the LUT still has only one
output you couldn't build an adder/subtracter, for which the carry
chain was optimized.

 

[John_H]

So to clarify:
You want 2 bits of "a" and 2 bits of "b" to drive the 16-entry LUT for the
carry chain select AND you want an 8-entry LUT for the Direct Input of the
carry chain mux?

"Brannon" <brannonking@yahoo.com> wrote in message
news:1129659685.077987.171750@g14g2000cwa.googlegroups.com...

You have a good point. I should have clarified. The subtraction only
uses two inputs per LUT. The same is the case with what you're
proposing for the compare. It seems to me you could double the density
by adding an extra switch bit to the MUXCY because the LUT already
supports four inputs.

 

[Bevan Weiss]

fahadislam2002 wrote:

Hi...again
First thanks for such a nice response...

As everyone suggested that donot try to use 1 or 2 layer but instead
go for four layer ...
but the problem is ... in my country (Pakistan) 4-layer is not
available... and as RAM is just a part of my final year project
(Designing of Gaming Console using FPGA) so obviously i donot have
much time to get 4-layer PCB from Abroad.
MY
NEED
As I need only 1MB to 4MB RAM with a better speed (as also want
to use it as Video RAM :? )
So I also tried to get chips.But here only 32KB is available
with a worst speed of 85 ns.
So for chips I contacted to Micron,s office in China (as not
present in my country).But they responded that they send a shipment
of atleast of $500...and I need only one or two SDRAM Chips of 16MB.

[b:d11e0ac89c][color=darkred:d11e0ac89c]Please
Suggest[/color:d11e0ac89c][/b:d11e0ac89c]

[color=darkred:d11e0ac89c]Query_1:-[/color:d11e0ac89c]
Where to Get a Cheap SDRAM chip (Better if micron
as i have done work with it) and also Video RAM .And more
importantly that i need just one or two
[color=darkred:d11e0ac89c]Query_2:-[/color:d11e0ac89c]
Where to get cheap 4-layer PCB or some alternative
of it.
[color=darkred:d11e0ac89c]Query_3:-[/color:d11e0ac89c]
Major area where i need more RAM (and also its
speed) is for Video RAM ,,,,,,,,,,,,suggest how can reduce this
need,,,,,,,,,,,,,
,,,,,,,,,,as if reduce it and get manage it on very less.....then can
try to use series of chips......... of RAM .

Waiting for Response :x

I haven't been following this thread, however it looks like you started
out by designing for RAM modules (ie PCBs containing several DRAM
chips). It then looks like you decided routing this on 1/2 layer PCB
would be too complex so you'd like to go to a 16MB DRAM chip.

I'd recommend that in all cases you will really need a 4 layer board.
This is especially true if you've only done a few board designs, and
certainly if you've never successfully completed one involving high
speed interconnects.

There are many good fast prototype board houses in the US, many will
produce 4 layer boards in under a week. So including shipping you could
have one in less than 2 weeks. The cost is also quite reasonable, maybe
a couple of hundred dollars for a one off.

You could then choose whether you'd prefer to route for a single chip
(or maybe a couple) or whether you'd prefer to include a RAM module slot
(which is what I'd do based on what the design seems to be for).

If you request some academic samples you may be able to obtain a couple.
I've had good experience with Micron in this regards before. Try
mentioning what you're after the samples for when you talk to your local
distributor. If they're not helpful, try a distributor slightly further
afield.

I'm surprised that you only mention issues with routing for your memory
modules. Have you had no other routing problems, such as the FPGA ->
host etc? 2 layers is really not that much when you've got to include
power and ground on them...
How are you getting your bitstream to the FPGA?

 

[John_H]

"im sure the connections are correct"

Is the IOBUF's input hooked up to the output from the core (which you
found is always ground) and is the I/O buf's output hooked up the the
input to your core? I've mentally stumbled on the .O feeding my inputs
and not being what I drive and vice-versa on the other side.

The .I is the input *to* the IOBUF and the .O is the output *from* the
IOBUF.

It's a shot.

- John_H


CMOS wrote:

i've done that already. im using IOBUF at the port. but at the
traslation stage it gives an error "ERROR:924" which says the port is
connectod to an non-buffered input.
in detail this is what i have.
i got six port signals comming out from the i2c interface to generate
that open drain "scl" and "sda" outputs. namely,
sda_pad_o - this is internaly connected to ground as you said. (port
type -out)
scl_pad_o - this too is internaly connected to ground as you said.(port
type -out)
sda_pad_oen - this is the buffer enable/disable output for sda.(port
type -out)
scl_pad_oen - this is the buffer enable/disable output for scl.(port
type -out)
sda_pad_i - this is the buffer enable/disable output for sda.(port
type - in)
scl_pad_i - this is the buffer enable/disable output for scl.(port
type - in)

what im doing in the top level design is to connect those signals to
two IOBUF's, where bidirectional pin of those two IOBUF's are used as
the final sda and scl. im sure the connections are correct. when i do
so, in the traslation phase it gives the error "ERROR:924".

Please help me on this.

p.s:
Im new to vhdl and FPGA and i got lot of questions, some of which are
very silly. But symon knew VHDL since his birth and im proud of him.
let me know a better forum if im too in-experienced here.

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/7bf06cf65c8e6a76/d33a8d735c04af66?q=clk+clock+coffee&rnum=1&hl=en#d33a8d735c04af66
or serch for "clk clock coffee cocoa" in this forum.

Thank you.
CMOS

 

[Zara]

On 19 Oct 2005 01:39:32 -0700, "starbugs" <starbugs@gmx.net> wrote:

Hi there,

I would be happy about some suggestions on how I could start to make my
design faster. My design is a processor (18 bit datapath)and the
critical path looks like this:

(...)
I notice that the net delay of the instruction register is quite high.
Does this have to do with the fanout? Fanout is 18 (because the value
is used as an address to 18 parallel distributed RAM LUTs). I've heard
of duplicated registers. Would that help? And then, how would I achieve
it? Automatically through a setting? Manually? Is there an elegant way
to do it?

Yes, your problem is fanout. Duplicating registers could be the
solution, but it has mainly two drawbacks:
- It usuallly uses more FPGA registers
- It may only move the fanout problem to the routing *before* the
register. You could kill this problem creating a new one.

Try experimenting with the synthesis/implementation options. For
instance, you could try to set maximum fanout to 10. In general, don´t
try to topimise by hand, let xilinx tool try to do it.

Set optimization goal to speed, use timing constraints... try
everything if possible.

BTW, I would register the multiplier outpu, call it
"productResultRegister" and use this resgiter as another one from the
register file. This way, instruction set might grow a little but
timing might improve. (Test before doing too radical changes!)

 

[Bevan Weiss]

CMOS wrote:

hi,
the IOBUF im using has 4 pins.
it is made of one TRISTATE output buffer and input buffer. the
inputbuffer's input and tri_state output buffers output is connected
together and function as the IO port for the entity. the input of the
tristate output buffer is connected to the output from the core, which
is always grounded. its enable/disable pin is also controlled by the
core. the output of the input buffer is connected to an input of the
core.

CMOS

Does the output from the core not just have two pins for SCL and another
two for SDA?

I'd have just thought that you'd have:
OE for SCL connected to SCL output from core
I for SCL connected to SCL input from core
OE for SDA connected to SDA output from core
I for SDA connected to SDA input from core

Which signals are available from this I2C core?

 

[John_H]

"the inputbuffer's input and tri_state output buffers output is
connected together"

and

"the input of the tristate output buffer is connected to the output from
the core"

seems to suggest an extra connection.

sda_pad_o to IOBUF.I
sda_pad_oen to IOBUF.T
sda_pad_i to IOBUF.O
pad to IOBUF.IO

similar for clock.




CMOS wrote:

hi,
the IOBUF im using has 4 pins.
it is made of one TRISTATE output buffer and input buffer. the
inputbuffer's input and tri_state output buffers output is connected
together and function as the IO port for the entity. the input of the
tristate output buffer is connected to the output from the core, which
is always grounded. its enable/disable pin is also controlled by the
core. the output of the input buffer is connected to an input of the
core.

CMOS

 

[Austin Lesea]

Martin,

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sSecondaryNavPick=&iLanguageID=1&multPartNum=1&category=&sTechX_ID=al_v4rse&sGlobalNavPick=&BV_SessionID=@@@@1217042584.1129733086@@@@&BV_EngineID=cccgaddfmiggfdlcefeceihdffhdfkf.0

is the long URL.

-snip-

Could you clarify something for me please? I have read the Rosetta
stuff that I could find, and I'm still not sure: The experiment is
testing the configuration latches only, not the flipflops I use in my
designs - is that correct? Can you point me at the document I need to
read more carefully

September Issue, IEEE Transactions on Device and Materials Reliability
has the Rosetta story.

For those who have IEEE library usernames and passwords, or those who
belong to this group, you may find the article online:

http://ieeexplore.ieee.org/Xplore/guesthome.jsp

Go to Journals & Magazines, and to this transactions, and "view
forthcoming articles."

Since we wrote this, IEEE owns the copyrights, and we can no longer
distribute the paper.

If you wish to have a presentation on Rosetta, our FAEs have powerpoint
slide shows on the subject they can present (under NDA).

Given your affiliation (TRW), I imagine you know who is your
Aerospace/Defense Xilinx FAE, and can contact him regarding this subject.

The Aerospace/Defense Group has further requirements from the commercial
group (heavey ions, total dose, etc.). These are addressed in other
reports and publications. Xilinx has a radiations effects industry
consortium with more than a dozen members who are actively working on
the use, use models, performance, and mitigation of radiation effects.
Please ask about this consortium.

We also have agreements with groups in the EU on the same subject,
directed from our research arm in Ireland (to facilitate better
communications).

Rick Katz of NASA (who posts here often) has proceedings from
conferences he can direct you to with even more information that we have
presented.

An example here is the MAPLD conference, 2005:

http://www.klabs.org/mapld05/abstracts/index.html


To answer your specific question: what about the D FF in the CLB? What
is it's Failure Rate in Time compared to the configuration bits?

There are 200,000 DFF in our largest part (XC4VLX200). the failure rate
of these is .2 FIT (ie 1 FIT/Mb). That is .2 failures in 1 billion
hours for the largest device (at sea level). The DFF is a very large,
well loaded structure as it is programmable to be: a latch, a D flip
flop, asynchronous reset, synchronous reset, with other options as well
for load, preset, and capture.

Compared to the 6.1 FIT/million bits of configuration memory (as of
today's readout) for the mean time to a functional failure, times the
number of config bits (in Mbit), the DFF upset rate is many times less.

We also are recording the upset rate in the BRAM.

In Virtex 4, we have FRAME_ECC for detecting and correcting
configuration bit errors, and BRAM_ECC for detecting and correcting BRAM
errors (hard IP built into every device).

Regardless, for the highest level of reliability, we suggest using our
XTMR tool which automatically converts your design to a TMR version
optimized for the best reliability using the FPGA resources (the XTMR
tool understands how to TMR a design in our FPGA -- not something
obvious how to do). In addition to the XTMR, we also suggest use fo the
FRAME_ and BRAM_ ECC features so that you are actively "scrubbing"
configuration bits so they get fixed if they flip, and the same for the
BRAM. The above basically describes how our FPGAs are being used now in
aerospace applications.

Austin

 

[Symon]

KB,
How about adding another multiplier so that you can eliminate the first mux.
Have one multiplier for each source. Then make the second mux one port wider
to accommodate the extra multiplier result. The Xilinx CLB muxes are
expandable without adding too much extra delay.
HTH, Syms.

"starbugs" <starbugs@gmx.net> wrote in message
news:1129711172.603645.233560@g14g2000cwa.googlegroups.com...

Hi there,

I would be happy about some suggestions on how I could start to make my
design faster. My design is a processor (18 bit datapath)and the
critical path looks like this:

1. Instruction register (containing number of register)
2. Register file (distributed RAM)
3. Mux (2-way, selects either register or RAM)
4. Mult18x18 within the ALU
5. Mux (ALU output selector)
6. Register file (distributed RAM)

 

[Ray Andraka]

none of them are really, however you can run the later ones at a
considerably reduced voltage to achieve dramatic power savings at the
cost of slower operation.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[luc]

Jim,

If I'm not mistaken, the datasheet of the 4000Z provides both static
power, and a graph showing the dynamic power requirements.
There is even a complete technical note about the power coefficients.

On the FPGA side, the Power Calculator can be used for static power,
and gives a very good idea of the requirements when a design is
loaded. Unfortunately this is only true if a full timing simulation is
done and the test vectors are fed back to the power calculator. If you
don't simulate, then you need to give an activity factor.

Luc

On Thu, 20 Oct 2005 07:58:05 +1300, Jim Granville
<no.spam@designtools.co.nz> wrote:

himassk wrote:
I could nt make out the best low power FPGA among the Spartan3, Cyclone
II and Lattice FPGAs.

Regards,
Himassk

You need to work it out for your application:
using the vendors mA(Static) and mA/MHz numbers, and also determine if
Typical, or Worst case matters most to you.
Actual measurements will probably be needed as reality checks.

Not all these numbers are clearly documented, and with everyone
claiming to be lowest power, your task will not be easy.

In particular, Look for what they do NOT say.

example: I see lattice make big claims for 4000Z static Icc over
coolrunner 2, but are very quiet on mA/MHz.
Perhaps that number does not stack up as well ?

-jg

 

[Mike Treseler]

Lionel Damez wrote:

The design seems to fit easily in a xc4vlx200

Looks like the logic fits but the wires don't.

Number used as Latches: 2,048

I wouldn't expect any latches.

What are the possible ways to help the par tool find a sucessful placement/route?

Try a simpler case first. Maybe four microblazes?

-- Mike Treseler

 

[Brad Smallridge]

Is this the ML403 board?

 

[Waage]

No, this is Avnet's Virtex-4 Evaluation Board. Not sure if it has
a corresponding reference rumber.
It does have Xilinx PROM and Xilinx's Virtex-4 on the board.

The ML403 is Xilinx's own Development Board

Chris

 

[Kunal]

What is the problem with the board? Maybe we can help.
I guess it is the 'Virtex-4 FX12 Evaluation Board' with the OLED.

Kunal

 

I think the problem is that the lame-ass Windows emulation libraries
have limited environment variable space. A typical BSD env is too long.
It works for me when I start it up with a minimum environment, like so:

$ env - PATH=$PATH HOME=$HOME sh
$ . settings.sh
$ ise


Darius wrote:

Still trying to figure out why my file dialogs complain about long
paths though..

 

[Antti Lukats]

"Waage" <chris@ednainc.com> schrieb im Newsbeitrag
news:1129865780.677607.22780@z14g2000cwz.googlegroups.com...

Thanks. When I posted I was pretty steamed was probably venting more
than
looking for help. But, here's some of the details.
I should have been more specific. It's the is the Virtex-4 LX60 Eval
Board.

I don't actaully know where the issue(s) is/are. It could be in one of
at least three places.

1. A board level issue.
2. The Platform Cable USB used to interface to JTAG
3. Xilinx's Impact software.

I have been attempting basic communication to the board. Nothing
fancy.
I tried using Impact's "Initialize Chain" command to see if the
software could
find and recognize the devices (PROM and Virtex-4) on the JTAG chain.

I get the following:

Identifying chain contents ....read count != nBytes, rc = 20000015.
read failed 20000015.
'1': : Manufacturer's ID =Unknown
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.

Hi Chris,

1) what avnet told you first was good and correct, its EASIER to get FPGA
tools to run on Windows then Linux. It just is like that.

2) Impact is not software. its nightmare.

3) USB Cable as the 'newest' one seems still to have most problems.

So you fixed issue 1 what is under your control, but now you are stuck with
an nightmare called impact and usb cable.

There is unfortunatly little you can do:

1) jtag chain debugging, with impact, measure signals... boring
timeconsuming most likely will only give you info that everything seems to
be ok and SHOULD work

2) try use ChipScope to check the chain, the low level drivers/access of
chipscope and impact are different, sometimes the other one works !

3) open webcase, and be ready to prepare lot of impact log file, they will
ask for them, or to speed up add the log files to your webcase to speed up
the issue.

4) make more steam to avnet

I could suggest to try our jtag software but as usb cable protocol is prop.
we dont support it (only parallel cables)

As the readback was something else than contstan 0or1 then I think the board
is not completly dead, and that the jtag chain actually is scannable, so its
some tool issue.

make sure the usb cable is updated, well in our case 1 of 2 usb cable
stopped to work completly after firmware update, but in that case you can
return it, or open another webcase

Antti
PS we have also an Avnet FX board (LX25) I idid order it the minut it was
announced, it was the FIRST V4 board announced as 'available' - first Avnet
did delay about 6 months !!! then when I got the board only to find out that
XMD does not suport usb cable and Virtex 4!!!! so I was not able todo any
EDK system debugging on that board. The board itself works also with usb
cable I think, the issue was only with the combination of V4+usb cable+edk
xmd