EDK : FSL macros defined by Xilinx are wrong

How did you arrive at the value 47 ( 2F hex) for the value 1.36.....

What if the number is 1.122 instead?....

Is there a technique to do that..

Thankyou
 
Thankyou Chris,
Instead of 2^24, we need to plug in the deicmal equivalent of the 24
bit input we have.

Is that right

And also,

recip <= conv_std_logic(2^24 * 1 / 1.36) -- not sure this is the right

I am not sure if this would work because it again uses the '/'
operator.

This cannot be synthesized in XST.

Thankyou
 
Helpful hint:
XC3000-type circuits are sensitive to slightly negative Vcc followed by
a fast ramp-up. This might upset the deliberate imbalance in the
configuration latches, and might (perhaps) cause a lock-up, although we
have no record of this. It is just an enlightened speculation on our
part.
15 years ago, the environment was generally slower, but now, especially
with ECL ciruits in the vicinity, there might be a chance for such
malfunction.

Just a guess and a helpful hint.
No response is needed, and, please, no insult.
Peter Alfke
 
One of the things that has been bothering me through all of this is your
detecting of a 16 MHz clock. The configuration clock for these devices is
nominally 1 MHz, but actually it can range from 500 KHz to 2 Mhz. I am
certain that it does not use a faster clock and then divide it down. So I
have been beating my head about what this 16 MHz is. Well, I just figured
it out.

The baseline family is XC3000

The XC3100 family was a higher performance family

The XC3000A family had some routing enhancements which made use of some
previously dummy bits in the config bitstream.

The XC3100A has both the higher performance of the XC3100 family, and
the routing enhancements of the XC3000A

The XC3000L is a low power derivative of the XC3000A

(FYI, all bitstreams are the same length. Designs compiled for the XC3000
or XC3100, can be used with any of the 4 families. Designs compiled for
the XC3000A or XC3100A, may make use of the dummy bit, and so these
bitstreams can not be used in the XC3000 or XC3100 devices).

The performance enhancement in the XC3100/3100A family is achieved by the
use of on chip charge pumps. These create higher voltages that are used
on selected circuits in the FPGA. These charge pumps use free running
oscillators that are separate from the config oscillator, and are almost
certainly the 16 MHz that you are seeing. There is no way to actually
measure these oscillators, other than what you are doing with the spectrum
analyzer.

Since you are seeing that the 16 MHz is not present in devices that are
not operational, this means that the charge pumps are not all running.
Under this situation, I would expect that the chips would be basically
non operational, and no amount of banging on reset, D/P, or other control
pins is going to help. This is what you have reported.

I don't remember if the problem you are seeing is that devices that
operational, stop operating, without turning the system off, or that
when a system is turned on, sometimes it does not start up correctly.
(Have you ever said this?)

At this point it would seem that either the profile of the powerup
voltages, transients on the power lines while operational, or maybe
negative transients on data lines.

As an example, I have seen DRAMs fail due to excessive undershoot on
a data line, that violates the devices max negative spec. This is
a failure mode different from the well known problem of latchup. I.E.
the device fails, but does not exhibit the high power consumption
associated with latch up.


Philip Freidin





===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
 
In article <1112290749.838313.314300@l41g2000cwc.googlegroups.com>,
genlock <genlocks@gmail.com> wrote:
How did you arrive at the value 47 ( 2F hex) for the value 1.36.....
Click to expand...
Because 64/47 is nearly 1.36, so multiplying by 47 and dividing by 64
is about the same as dividing by 1.36

What if the number is 1.122 instead?....
Click to expand...
1.122 is nearly 64/57, so multiplying by 57 and dividing by 64 is
about the same as dividing by 1.122

Is there a technique to do that..
Click to expand...
Given X, for example 1.122, work out w = 2^k / X for k from 1 to some
conveniently big number, and use the [k,w] pair that makes w nearest
to a whole number.

eg 1.5678, you try lots of k and find that 2^18 / 1.5678 is almost
exactly 167205.

This general technique is called fixed-point arithmetic.

Tom
 
Hi Jose,

You need to be more specific.
- what mode did you activate ? JTag ? Active serial ?
- What exact device are you targeting ?
- What device is selected in your project ?
- what did the scan chain command "Auto-detect" return ?
- Which file (extension) do you use for programming ?
- Are you sure you have only one single line in the table ?
- What option did you activate on the programmer widow ?
- What is the exact error message you got ?

qpf & qsf files are small and readable, you can cut and paste
to an email.
btw : Version 4.2 has been out for a while, no reason not to use it.


In doubt, create a trivial design : couple of lines in vhdl
with a blinking LED, clock and reset.
Do this in an empty drectory and go all the way down to programming.

Bert
 
John_H wrote:


The results may be consistent according to the Verilog Language Reference
Manual but I wouldn't expect it.
Click to expand...
Can you explain how ?
Is it clear from the Stratified Event queue (I mean the evaluation order ?)
 
Mark -

In testbenches, you typically want to be VERY careful to not let Z or X
values
accidently slip through as "don't cares". A lot of times, I'll code
testbenches like:
reg [15:0] expect;
reg [15:0] actual;

expect = 16'1234;
// get the actual value set...

if (actual !== expect)
begin
---complain---
end

Note the ! = = type compare. This means identically not-equal, no
"don't cares"
allowed. There is a corresponding === (3 equal signs).

Note that the OpenCores stuff is quite useful, but I usually have to
triple check
the code (and fix stuff) before I use it. It's usually a great
startying point for
study.

I hope this helps.

John P
 
depends on how the rom is generated. You can actually get it to create a
smaller ROM if lines are duplicated and it will reduce further that the 548
missing lines. You should however define any unused locations even if they
get optimised out.

Simon

"Acceed See" <invalicd@hotmail.com> wrote in message
news:424a1c0a@news.starhub.net.sg...
When I choose Distribute Memory -> Depth 2048 -> Width 64 -> ROM -> LUT
based,
and my .coe file contains only 1500 words, what will ISE do during the
P&R?
Will it
save the 548 words or implement them with zeros anyhow?

My FPGA has ample LUT remaining, but little BRAM. I need to plug in some
more data
which is meant to be put in the BRAMs. Where is the place I can store
these
data?
Click to expand...
 
Hi,
I dont know if this will help you are not..Did u include ur
component in *.pao file

--
Parag Beeraka
 
Ziggy <Ziggy@TheCentre.com> writes:
Does such an animal exist? I have looked around but
as of yet Ive not seen one. Saw reference to a couple
of non-open ones.

A x86 core would be nice too, but i doubt ill find
one of them due to IP rights...
Click to expand...
There's probably a lot less problem with IP rights on the x86 than on
the PowerPC. The x86 has been around long enough for the patents to
expire. (Maybe not on things like MMX and SSE, but you didn't indicate
that you needed those.)
 
Hi Peter,

I suspect the P&R tool, knowing the MRam is not initializable, may probably feel free
to connect the data and address pins in any order :-(
Hacking the simulation netlist automatically (Tcl script?) might be possible,
recognizing the bus order from the net names and rewiring them in an orderly fashion
to your own initialized model, but this doesn't seem obvious.

Pls keep us posted on your findings, this is an interesting case :)

Bert

Peter Y wrote:

For whatever reason, I need to be able to initialize the M-RAMs in Altera
chips, and I need to do this in a timing simulation, for which I use
Modelsim.

So I've hacked the stratix_atoms simulation libraries to initialize them,
and that works fine. I can start a simulation, look in those memories and
everything they have is correct, but now the simulation is incorrect.
Anyone know why this might be? Are the columns of the RAM permuted for
timing reasons, is it endianness, or anything else?

I need to do this with a lot of designs, so setting break points and using
the Update Embedded Memories in Quartus' simulator is annoying. Any other
suggestions?
Click to expand...
 
Eric Smith wrote:
Ziggy <Ziggy@TheCentre.com> writes:

Does such an animal exist? I have looked around but
as of yet Ive not seen one. Saw reference to a couple
of non-open ones.

A x86 core would be nice too, but i doubt ill find
one of them due to IP rights...


There's probably a lot less problem with IP rights on the x86 than on
the PowerPC. The x86 has been around long enough for the patents to
expire. (Maybe not on things like MMX and SSE, but you didn't indicate
that you needed those.)
Click to expand...
I hadnt thought about the patents expiring on the older X86 stuff, which
would suit the bill fine. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.

I also thought that PPC was more like ARM and SPARC, and the specs were
available openly, just that it would cost to be 'certified' ( which in
my case doesnt matter ). But ive been wrong before ;)
 
The latest Microblaze version has an optional single-precision hardware
Floating Point Unit (FPU):
http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf

Herb T wrote:
Folks,
I'm looking at a design problem that may need a floating point unit
(single precision is fine). Part of the unknown at this point is that
it would be running with the Microblaze embedded soft core on a Spartan
3S400. Do you have any recommendations for an FPU? Does such a
configuration leave room (system gates, on-chip resources, etc) for
anything else in terms of running a DSP type calculations (e.g.
adaptive filters) and device control? I've seen the core provided by
Quixilica, but would prefer to go to something free or open source due
to the fact that I may find out it's not the solution, esp for the
prototying phase.
Thanks,
-HT
Click to expand...
 
parity wrote:
Hello,

i'm from germany and just registered to this forum. Hello to
everybody
out there.

I'm working on very small FPGA Designs which are size-comparable
(about 4-40 Look-up-Tables on a VIRTEX FPGA) to 4 Bit-adders and 4
Bit-multipliers. I use them just for testing some things. The problem
is that I use XPower to calculate the power consumption of the
designs
and the power values are not what i expected.

I have a testbench, an input stimuli and the placed and routed
design.
Whenever i put stimulis to the design it delivers (like expected) the
"mW" values. But if i change the stimuli to other ones, which are
nearly the same, the power consumption raises to the double or stays
the same. (after subtracting the quiescent part). There's (in most
cases) nothing between them.

Does anybody know this problem? Have I reached the smallest possible
XPower value, or what is it?

Oh, and does anybody know, how accurate XPower should be. Is there a
chance to get some information about it?
Click to expand...
Howdy,

Xilinx tries to make XPower as accurate as possible - otherwise why
would people bother to use it? Is it possible there are bugs and
you've stumbled upon one? Absolutely.

Respectfully, not knowing exactly which FPGA, which version of XPower,
which things you are changing between runs (code or otherwise), or
which items within the FPGA that are actually being used to implement
your different designs (shown in the .mrp file for each run), it is
impossible to answer your question with any accuracy.

Think of it like this: it would be the same if you just asked us why
your car is _somtimes_ getting poor gas milage. But you don't give any
info on the car, your actual milage, your expect milage, where you're
driving, how you're driving.

Have fun,

Marc
 
Have your program/script create a package file with a
constant table and include it in your probject. You
can then "use" the package in your architecture and
directly use the constant table.


Andrew Whyte wrote:

Thanks for your reply Mike. Ideally I'd like to read any kind of memory
configuration file into a design with Synplify - doesn't have to be
Xilinx-specific formats.

With XST, what I can do is read in a .mif file and then parse the data
to create init values for my memory elements. Synplify does not appear
to able to do the file read.

Any more ideas?

Andrew

Mike Treseler wrote:

Andrew Whyte wrote:

Hi,

I'm trying to read in data from a .mif file to initialise some memory
elements in Synplify 7.6.1, but it fails when it encounters the line

FILE initfile : TEXT;



A .mif file is specific to X devices.

Synplify can synthesize variable or constant
arrays into ram or rom using only vhdl source code
for any fpga.

Vendor-specific download widgets are handled with
vendor attributes in the code like this:

http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/vtex11.html

But consider maintaining vendor-independent code.
That's a common reason for using Synplify over XST
in the first place.

-- Mike Treseler
Click to expand...
 
In article <XYS3e.131292$r55.32410@attbi_s52>, Ziggy wrote:
I hadnt thought about the patents expiring on the older X86 stuff, which
would suit the bill fine. A reproduction of a 486 or base Pentium would
be plenty for what i want to do.
Click to expand...
I doubt it's a matter of patents, but more a matter of licening. The two
are very different beasts. Having said that, what you do in your own home
for your own amusement is your business... :)

--
[100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
 
Tobias Weingartner wrote:
I doubt it's a matter of patents, but more a matter of licening. The two
are very different beasts.
Click to expand...
But if there isn't a patent on an architecture, you don't need a license
to implement it. The purpose of the license is to grant you a right that
was taken away from the patent. If there's no patent, you haven't been
denied the right.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top