EDK : FSL macros defined by Xilinx are wrong

[larwe]

Eric wrote:

Does anyone know of a 6V 12Ahr Sealed Lead Acid Battery that has been
able to pass FM's or ATEX short circuit temp. rise test?

Umm... did we try google "factory mutual sla battery"?

Multiplier Industries Corp. - http://www.multiplier.com/
Manufactures rechargeable Ni-Cd, Ni-MH, Li-Ion and Factory Mutual
approved batteries custom packaged for the OEM.

But there are plenty of SLAs available, also try Rocket (Global &
Yuasa) and Casil (Chee Yuen) as I know these specific brands, among
others, are used in FM-listed fire panels.

 

[Andy Peters]

air_bits@yahoo.com wrote:

Eric Smith writes:
How would you write it if you did NOT want a flip-flop, but only
a combinatorial output?

Depends on the tool. TMCC/FpgaC registers the state of every
variable by default, and it takes a minor edit of the output netlist
to remove the register.

Seems to me that editing the output netlist is akin to editing a PCB
design's Gerber files. There's a disconnect between the source, which
in the FpgaC case is the C source file and in a PCB design the
schematic, and the result, meaning either the final FPGA load or the
finished PCB.

In other words, I want to look at the source and know that it matches
the hardware.

-a

 

[Eric Smith]

I wrote:

How many real-world designs have NO combinatorial outputs?

air_bits@yahoo.com writes:

How many PIC's and other microprocessors have combinatorial outputs?
Maybe None?

Actually I've used the analog comparators that are available on many PICs
as combinatorial logic.

 

[Mike Treseler]

air_bits@yahoo.com wrote:

Mike Treseler wrote:
This style feels somewhat C-like but the
template keeps me in "think hardware" mode.

Yep. Then the big difference starts, debugging in "think hardware"
mode, or debugging in "think software" mode using source level
debuggers with break points, single stepping and variable watching
at a high level.

Modelsim does all of that for vhdl or verilog source code as well.
In a single-process (or always block) design, tracing just
one thread and watching variable values is very
effective way to debug the logic description.

-- Mike Treseler

 

Hi stephane,

Which OS are u planning to boot ?


U boot has a port done for the xilinx ML300 Board.

Take a look at the source code of Uboot , will be a good starting
point.

I am looking in exactly to do something similar like yours.

 

[Totally_Lost]

Andy Peters wrote:

air_bits@yahoo.com wrote:
Eric Smith writes:
How would you write it if you did NOT want a flip-flop, but only
a combinatorial output?

Depends on the tool. TMCC/FpgaC registers the state of every
variable by default, and it takes a minor edit of the output netlist
to remove the register.

Seems to me that editing the output netlist is akin to editing a PCB
design's Gerber files. There's a disconnect between the source, which
in the FpgaC case is the C source file and in a PCB design the
schematic, and the result, meaning either the final FPGA load or the
finished PCB.

In other words, I want to look at the source and know that it matches
the hardware.

If that is what you want, you are certainly free not to do anything
special.

From a software perspective it's pretty common to use a tool to produce
the prototype, and then to use a script to fix/edit that prototype to

create
the final form for production. The general key is to document the
process
well, and manage it. The whole Xilinx tool chain used to be a series of
net list edits from front to back, including the back annotation. I
assume
there are others that are also comfortable with post processes net
lists
with C and Perl tools to fix vendor bugs and to implement design
requirements the vendor tool chain can not handle directly. In comes
down to understanding the process you have, the changes needed to
effect the desired results, and documenting the modified process
carefully.

Post processing even Gerber files is very common. PCB houses used to
do it regularly to adjust soldermasks and still do it for panalizing
and inserting
dead or active copper to manage plating density. Again, managed editing
of the bit stream to finished product.

For years we used to post process C compiler output to fix known bugs
on binary compiler products, and to do custom peep hole optimizations
for specific target architectures. We used to use perl scripts to
insert
a new wrapper for C coded interrupt routines instead of having a lame
asm wrapper. Of course, you can always bug report it, and wait till the
next release to continue development or get the bugs fixed in the
field.

Everyone has there own comfort level and standards.

 

[Hal Murray]

Does anyone have some advice for the fastest say to get many MBytes of
data from a Spartan3 fifo to the hard disk of a PC via usb. I assume
that it is a combination of the best USB interface next to the FPGA and
perhaps a USB chipset in the PC that can do some very clever DMA.
I don't want to mess with custom RAID stuff I just want to dump it to a
standard hard disk & controller.

How fast do you expect to go? How fast is your disk? How fast is
your USB? How fast is your PCI?

My guess is that your disk is the limiting factor. If your PCI
bus is twice as fast as your disk, then you can read the bits
into memory and write them out to disk. If you have a driver
for your USB gismo, that's probably the simplest overall.

Write some hack code to test/measure it. If anybody needs it,
I'll dredge out some linux/unix code that I used to measure
disk transfer rates. (Hint: The outside edges are much faster
than the inside edges.)

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[John Adair]

We use bus switches in our PCI development boards and they are a good
solution. You should not have to alter your drive because they are in
series. A typical bus switch is usually represents a series resistance of
about 5 ohm or less and generally does not have much effect. Timing wise
most are quoted with a through propagation time of less than 250 pS.

As to compliance you probably find it is either the capacitive load, or the
trace length from the connector that don't meet the specification. We have
never seen or heard of an issue with our own boards when using bus switches
in the PCI interface.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Cheap Spartan3 PCI Development
Board.
http://www.enterpoint.co.uk


"Krzysztof Przednowek" <nospam@gazeta.pl> wrote in message
news:dl4lej$ham$1@inews.gazeta.pl...

Hi,
I'm tring to use my PCI core, with AVNET's Spartan3 400 evaluation kit.
What value should have 'Drive strenght' & 'Slew rate' in constrains?
Currently drive strenght is 12mA which is default for PCI33_3.3V. But
betwen FPGA and PCI slot there are level translators 3.3V->5V, so maybe
should be 24mA, or somethig else?
Board's documentation states that, board is not 100% compilant to the
PCI specification but should works in most systems. Anybody knows in
what areas this board is not 100% compilant? And at which systems don't
work? Currently I'm tring use it with BX based motherboard. And actually
system don't boot up. When I've try on NForce3 chipset motherboard
system have worked, but my board haven't been detected.

Best Regards
Krzysztof Przednowek

 

[Antti Lukats]

"Krzysztof Przednowek" <nospam@gazeta.pl> schrieb im Newsbeitrag
news:dl4lej$ham$1@inews.gazeta.pl...

Hi,
I'm tring to use my PCI core, with AVNET's Spartan3 400 evaluation kit.
What value should have 'Drive strenght' & 'Slew rate' in constrains?
Currently drive strenght is 12mA which is default for PCI33_3.3V. But
betwen FPGA and PCI slot there are level translators 3.3V->5V, so maybe
should be 24mA, or somethig else?
Board's documentation states that, board is not 100% compilant to the
PCI specification but should works in most systems. Anybody knows in
what areas this board is not 100% compilant? And at which systems don't
work? Currently I'm tring use it with BX based motherboard. And actually
system don't boot up. When I've try on NForce3 chipset motherboard
system have worked, but my board haven't been detected.

Best Regards
Krzysztof Przednowek

1) does the board worj when you use Avnet ref design image ?

2) the 24ma would not help, you have some problem with your core that
is the reason for the freeze

* the 3.3 <> 5V translators dont much matter
* the not fully compliant most likely is also not a problem at all

! make sure you have "unused IOB FLOAT" in the bitgen options
or some unused PCI pin may get pulled

and I suggest you start testing and analyzing some existing and
working PCI design before trying your own, and for your
own core make sure it works in testbench

http://ebook.openchip.org/

there is included a very simple PCI core that we have verified on
several boards - I am pretty sure it would work as soon as
you setup the .ucf pin locations properly

Antti

 

[Simon Peacock]

There are three things here.. what don't you understand?? They are both
basic concepts
1/ GBUFs (global clock buffers) are for driving internal clock nets.
2/ if it looks like a clock then its ok...
3/ clock out = any bit of a binary divide by n counter.

What's so hard about any of those ?
If you are finding English difficult.. I would suggest finding a translator

If you don't understand the basics of digital logic.. get a book and
learn... FPGAs are no different to a PCB with its logic... only its smaller,
faster and bugs are easier to fix. (mostly)

Simon

"Marco" <marcotoschi@nospam.it> wrote in message
news:dl1opq$88v$1@nnrp.ngi.it...

"Simon Peacock" <simon$actrix.co.nz> wrote in message
news:43745f0f@news2.actrix.gen.nz...
It doesn't really matter how you create it.. as long as its in the right
phase for what you need to do... just try to avoid outputting the output
of
a GBUF.
I think the best output is a divide of one of the system
(internal)clocks.

Simon



Sorry Simon, but I don't have understood.

Could you explain please?

Thanks
Marco

 

[Kolja Sulimma]

John Adair schrieb:

As to compliance you probably find it is either the capacitive load, or the
trace length from the connector that don't meet the specification.
The plain fact that there is a level translator present is a violation

of the specification.
Section 4.4.3.4:
"It is specifically a violation of this specification for expension
boards to:
* Attach any pull-up resistors or other discrete devices to the PCI
signals, unless they are placed *behind* a PCI-to-PCI bridge."

We have
never seen or heard of an issue with our own boards when using bus switches
in the PCI interface.

This seems to be general consensus. The PCI-spec just is to old to
foresee todays voltage level problems. When the spec was written they
could not imagine any good use for discrete devices on the signals but
they were allready seeing abusive use of discrete devices in prototypes.
So the board forbid them.

Kolja Sulimma

 

[John Adair]

That depends if you have a RAID array but certainly a restriction on signle
disk systems.


"Simon Peacock" <simon$actrix.co.nz> wrote in message
news:4376e6b2@news2.actrix.gen.nz...

Actually.. its not the PCI or USB that will kill you.. its the hard disk
write speed. 28 Mbytes/sec to 58Mbytes/sec

Simon


"John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote
in
message news:1131713514.31956.0@nnrp-t71-02.news.uk.clara.net...
I'll add to that and say that the USB controller in the PC is probably
sitting on a PCI bus or at least affected by the traffic on it. Also
worth
saying fastest USB is 480 MBit/s excluding overheads and 32bit/33MHz PCI
is
1056 MBit/s excluding overheads.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk


"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message
news:43746c57$0$355$da0feed9@news.zen.co.uk...
Hi
Does anyone have some advice for the fastest say to get many MBytes of
data from a Spartan3 fifo to the hard disk of a PC via usb. I assume
that it is a combination of the best USB interface next to the FPGA
and
perhaps a USB chipset in the PC that can do some very clever DMA.
I don't want to mess with custom RAID stuff I just want to dump it to
a
standard hard disk & controller.
Any pointers appreciated.
Colin


Colin,

I think a PCI interface capable of bus mastering will still be faster
than
a USB2.0 interface.

The PCI performance is slightly un-deterministic as it depends what
else
is
on your bus, but from what I've read here over the years I think 80MB/s
is
a reasonable expectation.

I half remember reading that although USB 2.0 gives you 460(?) Mb/s
that
this doesn't directly translate ~ 460/8 MB/s of data through-put (ie
60MB/s).


Nial.


-------------------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk

 

[Ajay]

Thank you so much Peter. We are using the 4:1 rule.

Regards,
Ajay

Peter Alfke wrote:

Yes, I agree.
Inside the chip, we make sure that the delay tolerances on a global
clock are less than the min delay clock-to-Q, and we can guarantee
that, since delays track inside the chip.
Between chips, the min delay is important since the clock delay
differences are determined by the pc-board, and the transmitting device
may also have nothing in common with the receiving device (neither
temperature nor processing, although probably voltage).

That's why source-synchronous design is now popular (sending the clock
together with the data) and IDELAY in Virtex-4 gives you the ability to
delay clock or data by a precise amount, so that you can achieve
near-optimal relative timing.
Peter Alfke

 

[John McCluskey]

I've some good news to relay on the ISE 8.1 front... I got a beta
recently on a DVD... It installed flawlessly on a Knoppix Debian
(4.02 I believe) machine. New 2.6 kernels don't seem to be a problem,
unlike the horrific installation difficulties of ISE 7.1 with recent
distros.

More good news... Webpack ISE 8.1 includes Coregen, and ... wait for it...

FPGA EDITOR!!!

(this was mentioned in the previous articles, but I think it deserves more
celebration

Plus the ISE 8.1 Webpack now supports the ISIM simulator under Linux,
which can now do mixed mode VHDL/Verilog simulations.

I'm guessing the Webpack release will be just before Christmas.

John

 

[Kim Enkovaara]

Mike Treseler wrote:

I use single process entities
with no signal declarations.
I declare process variables for every
local register and output port.
I use functions to create values
and procedures to collect and name
all repeated command sequences.

That can be a dangerous style. Some tools are quite bad with VHDL procedures
and functions. I have seen a some formal tools to create just insane
netlists out of procedures, some synthesizers can have problems with them.
Also some code chekers understand procedures quite badly and can show
problems that are not real (they can't figure out the control flow and
report extra latches that are not in reality there etc.)

Procedures are nice way to make the code clear to read, but unfortunately
the tool support is still problematic. I can't understand what is so
difficult in that support.

--Kim

 

[john]

Thanks all for suggestions.

with my version of ISE, I can not put the IOB attribute on a signal: I get the error

ERROR:HDLParsers:1202 - "/home/XXX/XXX/XXX.vhd" Line 210. Redeclaration of symbol tristate_enable_reg. -->

(the same attribute on the process generates no error but no IOB register.)

My workaround is to put the clocked process into a file: register.vhd

then I put the attribute on the instantiation of the component.

 

[Mike Treseler]

Kim Enkovaara wrote:

Mike Treseler wrote:

I use single process entities
with no signal declarations.
I declare process variables for every
local register and output port.
I use functions to create values
and procedures to collect and name
all repeated command sequences.


That can be a dangerous style. Some tools are quite bad with VHDL
procedures and functions.

I use modelsim, leo and quartus and have
not had a bit of trouble.

I have seen a some formal tools to create just insane

netlists out of procedures, some synthesizers can have problems with them.

I would not use such a tool.

-- Mike Treseler

 

[fjh-mailbox-38@galois.com]

johannes.vanderhorst writes:

But it can be tricky applying the GPL to an HDL project, because
traditional concepts like source code and binary executables are
transferred to a domain with source, several intermediate netlist
formats, some of which can be regarded as source when you're wide
awake...

The GPL defines what source code means:

| The source code for a work means the preferred form of the work for
| making modifications to it. For an executable work, complete source
| code means all the source code for all modules it contains, plus any
| associated interface definition files, plus the scripts used to
| control compilation and installation of the executable.

In general, if a HDL source is automatically compiled to hardware via
several intermediate netlist formats, only the original file(s) that a
human wrote should be considered the source for the purposes of the
GPL, since only those are the "preferred form ... for making
modifications to it." If the programmer has been
using scripts to tweak the intermediate netlist files, then those
scripts are also part of the source. If the programmer has been
manually tweaking the intermediate netlist files, then the manually
tweaked files must also be considered as part of the source, in
addition to the original source files.

 

[fjh-mailbox-38@galois.com]

Mike Treseler writes:

Problem 1.

There are ten times as many software designers
as digital hardware designers.

Solution 1:

Develop high-level languages for hardware design. Make these similar
enough to existing software development practices that developers only
need a general understanding of hardware optimization techniques (e.g.
pipelining, resource sharing, etc.), available hardware resources (e.g.
LUTs
and BlockRAMs), and how high-level language constructs map onto those
hardware resources. Then one hardware engineer can easily train up 10
software engineers to the level of hardware knowledge that they need in
order
to be able to productively develop efficient hardware using a
high-level language.

--
Fergus J. Henderson "I have always known that the pursuit
Galois Connections, Inc. of excellence is a lethal habit"
Phone: +1 503 626 6616 -- the last words of T. S. Garp.

 

[fjh-mailbox-38@galois.com]

Eli Hughes writes:

I seriously doubt you see anything much bigger that the snippets on Open Cores.

A lot of people once seriously doubted that we'd ever have
full-featured high-quality open-source compilers (GCC, lcc, etc.),
operating systems (Linux, *BSD, etc.), office software (OpenOffice,
KOffice, etc.), and so on. Those people were wrong.

Open-source efforts like OpenCores, GRLIB/LEON, FpgaC, JHDL, etc. are
just the start of a trend that is only going to get stronger as time
goes by.

--
Fergus J. Henderson "I have always known that the pursuit
Galois Connections, Inc. of excellence is a lethal habit"
Phone: +1 503 626 6616 -- the last words of T. S. Garp.