EDK : FSL macros defined by Xilinx are wrong

[John Providenza]

I did a quick & dirty project based on the OpenCores USB 1.1
design and drove the D+ and D- pins straight from the FPGA.
I wasn't concerned about strict compliance to the USB spec...

I got the project to work fine, but I only tried it on a couple
of computers. Different USB hosts might complain about the
direct D+ D- interface.

I did have to do some mods to the OpenCore USB design. As I looked
though it I found some things I was not real happy with. There was
no problem meeting timing with the Xilinx Spartan-2 chip I used.

John Providenza


"Ken Land" <kland1@neuralog1.com> wrote in message news:<vme5iv66sv911@news.supernews.com>...

Is it free?

That is very interesting and that is what I went looking for. I imagined
the logic in the FPGA would wiggle D+ and D- appropriately. I understand
that the 480Mbps of 2.0 might be tough in a garden variety FPGA, but 1.1
might be doable.

I wonder if the special LVDS pins of a Cyclone or Stratix would do 2.0? Of
course going to Stratix would negate any BOM savings.

Ken

"Antti Lukats" <antti@case2000.com> wrote in message
news:80a3aea5.0309152348.5ffd5049@posting.google.com...
"Kenneth Land" <kland1@neuralog1.com> wrote in message
news:<vmcl99c2s5jgc0@news.supernews.com>...
Have you looked at the USB 1.1 and 2.0 IP Cores at www.opencores.com?

I looked very closely at the 1.1 version and found it took only 6 pins
and
$1.75 transceiver chip.

Ken

there is a japanese design (VHDL, and Visual basic host example)
that uses no tranceiver at all, ie USB DM,DP directly to FPGa

antti

 

[Andyman]

PJ wrote:

Hello,

I am implementing a 128 point real Radix-2 fft, data and coefficient
widths are 16 bit.
I am synthezising it for use in an FPGA. However, it is taking a very
long time to synthesize. (approx 3 days using Leonardo on a 2 GHz
machine with 512 MByte RAM) I am using a 20K1000 Altera FPGA. The ram
required by the fft will be internal to the FPGA

Hiya,

I have noted with some synthesizers that if it cannot infer your RAM
"correctly" it will try to build it out of registers (as opposed to
the dedicated RAM on the FPGA). This can end up taking a _very_ long
time for only reasonably large RAMs.

You might consider synthesizing each module in your design separately
until you find the part that causes the problem. If it isn't already
structured thus it might be wise to do so as this may also help.

Later,

Andyman.

 

[Steve Casselman]

Wow, microblaze has a forum?!? I sure wish Altera would take a que and do
the same for Nios.

Why not bypass Altera and start a yahoo group for the Nios?

Steve

 

[Ken Land]

John,

That's pretty cool. I might try it some day after I get some more
experience under my belt.

My problem was that I needed an fpga IP solution at an OTS price and
reliability, but all I found were extremes. Either the core was "free" and
not guaranteed fully compiant or the price was sky high. So I wound up
sticking with my old reliable NetChip @ $8.

Ken

"John Providenza" <johnp3+nospam@probo.com> wrote in message
news:349ef8f4.0309161316.62c75235@posting.google.com...

I did a quick & dirty project based on the OpenCores USB 1.1
design and drove the D+ and D- pins straight from the FPGA.
I wasn't concerned about strict compliance to the USB spec...

I got the project to work fine, but I only tried it on a couple
of computers. Different USB hosts might complain about the
direct D+ D- interface.

I did have to do some mods to the OpenCore USB design. As I looked
though it I found some things I was not real happy with. There was
no problem meeting timing with the Xilinx Spartan-2 chip I used.

John Providenza


"Ken Land" <kland1@neuralog1.com> wrote in message
news:<vme5iv66sv911@news.supernews.com>...
Is it free?

That is very interesting and that is what I went looking for. I
imagined
the logic in the FPGA would wiggle D+ and D- appropriately. I
understand
that the 480Mbps of 2.0 might be tough in a garden variety FPGA, but 1.1
might be doable.

I wonder if the special LVDS pins of a Cyclone or Stratix would do 2.0?
Of
course going to Stratix would negate any BOM savings.

Ken

"Antti Lukats" <antti@case2000.com> wrote in message
news:80a3aea5.0309152348.5ffd5049@posting.google.com...
"Kenneth Land" <kland1@neuralog1.com> wrote in message
news:<vmcl99c2s5jgc0@news.supernews.com>...
Have you looked at the USB 1.1 and 2.0 IP Cores at
www.opencores.com?

I looked very closely at the 1.1 version and found it took only 6
pins
and
$1.75 transceiver chip.

Ken

there is a japanese design (VHDL, and Visual basic host example)
that uses no tranceiver at all, ie USB DM,DP directly to FPGa

antti

 

[Lasse Langwadt Christense]

rickman wrote:

Lasse Langwadt Christensen wrote:

Antti Lukats wrote:

"Kenneth Land" <kland1@neuralog1.com> wrote in message news:<vmcl99c2s5jgc0@news.supernews.com>...


Have you looked at the USB 1.1 and 2.0 IP Cores at www.opencores.com?

I looked very closely at the 1.1 version and found it took only 6 pins and
$1.75 transceiver chip.

Ken


there is a japanese design (VHDL, and Visual basic host example)
that uses no tranceiver at all, ie USB DM,DP directly to FPGa

antti

I've thought about that, two pins programmed for 3V3-cmos should be good
for tx and rx of SE0 but I never got around to checking if one of the
differential standards on the FPGA would be within spec for USB?

-Lasse


It has been awhile since I looked at the USB spec, but I seem to recall
that there is a non-standard state that is used to signal the rate or
some other aspect of the interface. I want to say this state is both
signals high or both low at the same time. Am I out to lunch on this?

If there is a non-standard state on these pins, you would not be able to
use an LVDS driver. You would need two independant outputs.

single ended zero (SE0) is both both pins low and afair you have to both
detect and generate that, my idea was to use two standard cmos IO's
for that and wire a diffential set in parallel.

-Lasse

 

[Uwe Bonnes]

John Providenza <johnp3+nospam@probo.com> wrote:
: I did a quick & dirty project based on the OpenCores USB 1.1
: design and drove the D+ and D- pins straight from the FPGA.
: I wasn't concerned about strict compliance to the USB spec...

: I got the project to work fine, but I only tried it on a couple
: of computers. Different USB hosts might complain about the
: direct D+ D- interface.

: I did have to do some mods to the OpenCore USB design. As I looked
: though it I found some things I was not real happy with. There was
: no problem meeting timing with the Xilinx Spartan-2 chip I used.

Do you plan to conmtribute the mods back? It would be appreciated...

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Uwe Bonnes]

John Providenza <johnp3+nospam@probo.com> wrote:
: I did a quick & dirty project based on the OpenCores USB 1.1
: design and drove the D+ and D- pins straight from the FPGA.
: I wasn't concerned about strict compliance to the USB spec...

: I got the project to work fine, but I only tried it on a couple
: of computers. Different USB hosts might complain about the
: direct D+ D- interface.

: I did have to do some mods to the OpenCore USB design. As I looked
: though it I found some things I was not real happy with. There was
: no problem meeting timing with the Xilinx Spartan-2 chip I used.

Do you plan to contribute the mods back? It would be appreciated...

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Kenneth Land]

Well, no good answer yet, but I figured out how to make it much easier to
restore all of the broken connections:

Turn OFF Use Rubberbanding in the Tools->Options->Block/Symbol
Editor->General dialog.

Now you can move the block such that all the old pins realign and reconnect.

Still, seems braindead for connections to break if the pin/signal names have
not changed and I would like to know if this is avoidable.

Ken

"Kenneth Land" <kland1@neuralog1.com> wrote in message
news:vmf84etmtns5a1@news.supernews.com...

Can anyone tell me how to avoid redoing all the Nios block port
connections
whenever I edit the processor config?

Whenever I add something to the Nios config in SOPC builder and update the
block, all of my connections are broken and all I know to do is reconnect
them one at a time manually. This takes quite awhile.

Is there anyway to have the update preserve the existing connections? It
seems to be based only on physical possition within the graphical editor
which seems strange to me.

Thanks,
Ken

 

[Jesse Kempa]

I'm not sure what your cost requirements are, but for getting off the
ground one recently released development platform comes to mind....
check out Omniwerks (www.omniwerks.com), who offers a complete 802.11
FPGA/Embedded CPU development kit, with board/software/IP. They use
the Nios CPU & uc/OS II operating system on the software side.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

The reason I went for fpga was to have wireless networking (802.11)
Actually, the sensors are 3-4 miles apart, I need the data until a
base station from where I will transfer the data to the internet.
the base station is located in the filed and will be 1-2 miles distant
from each sensor. So how do I transfer (in realtime) the data until the
base station from the sensor. Is it possible with PCI micro.
Please suggest me if there is a better solution other than fpga cpu
for doing this (wireless networking).

Thanks in advance
Srikanth

 

[Jesse Kempa]

Ken,

This seems to be an evil of block-based schematic design. The more
traditional blocks that we'd instantiate have a fixed set of ports...
and no need to move connections around. For SOPC-type systems where
peripherals and memory are added (or removed) with a mouse click, it
becomes more difficult.

One trick I use is to highlight an area in the schematic file
containing groups of pins & wires (connected to a block), and then cut
& paste them to a blank area of schematic (for example the SDRAM pins
as a group). Since the sets of IO for some piece of IP such as the
SDRAM controller don't change, any update you do to a Nios/SOPC system
will produce part of the schematic block with the exact same
arrangement of IO ports... after modifying my system (and having the
schematic block updated), I just select (as a group) the original IO
pins, and drag them to connect up to the schematic block.

It seems though, that many folks are steering away from schematic
blocks because of this in complex designs, in favor of hierarchic HDL.
This approach can be taken for Nios designs as our top level (from
SOPC Builder) is in fact an HDL file, but we provide schematic
top-levels in our example designs for clarity & getting started
purposes.

Jesse Kempa
Altera Corp.
jkempa at altera dot com



"Kenneth Land" <kland1@neuralog1.com> wrote in message news:<vmf84etmtns5a1@news.supernews.com>...

Can anyone tell me how to avoid redoing all the Nios block port connections
whenever I edit the processor config?

Whenever I add something to the Nios config in SOPC builder and update the
block, all of my connections are broken and all I know to do is reconnect
them one at a time manually. This takes quite awhile.

Is there anyway to have the update preserve the existing connections? It
seems to be based only on physical possition within the graphical editor
which seems strange to me.

Thanks,
Ken

 

[Andrew Paule]

What format are they in?

Michael Dunbar wrote:

Is there a viewer for the schematic files generated by the Actel
Desktop package.

We have some designs generated with this package, no longer supported
by Actel, license expired, original PC upgraded, and wish to view the
schematics.

Michael Dunbar
EW Simulation Technology Ltd

 

[John Providenza]

I used Webpack version 5.x a while ago and was able to
access block rams by infering them rather than instantiating
them. I don't know if this worked in version 4.x. For this
approach to work, you need to craft your Verilog code to match
the BRAM structure so the synthesizer could see that you REALLY
want BRAM and not distributed ram. It took me several iterations
to find the proper Verilog style.

Here's code that seemed to infer BRAM for a Spartan chip:

// ____________________________________________________________
// IN Buffer
reg [7:0] in_buf [511:0];

reg [8:0] in_rd_addr;
always @(posedge clk)
if (fifo_rd_valid)
in_buf[in_ptr] <= fifo_rd_data;

always @(posedge clk)
in_rd_addr <= next_in_rd_ptr;

assign fast_rd_data = in_buf[in_rd_addr] ;


Good Luck!

John Providenza


Marc Guardiani <marc@guardiani.com> wrote in message news:<%0K8b.1112$Kt4.203@nwrdny02.gnilink.net>...

Matt,

Thanks for the info. I looked at the Xilinx web site and what they are
now calling Foundation is not what they had called Foundation
previously. Previously, ISE started and Foundation ended with version
4.x (which used Aldec technology). What they are now calling Foundation
is something completely different than what I was refering to. I stand
corrected.

Marc


Matt wrote:
Marc,

Xilinx has four versions of their ISE software. They are:

1) Webpack
2) BaseX
3) Foundation
4) Alliance

1 and 2 are subsets of Foundation which has the XST synthesis tool. The
differentiator is that #3 has the full toolset with support for all Xilinx
devices. Numbers 1 and 2 have XST but only support the low to mid range
devices. Alliance is the third party flow which does not include XST.
It should be noted that XST does not support devices based on the 4000
architecture. i.e. 4000 family, Spartan/Spartan XL. All other families are
supported. If you need support for the 4000 stuff you need to go third
party.

Hope this helps...


Matt

"Marc Guardiani" <marc@guardiani.com> wrote in message
news:R_u8b.758$U41.369@nwrdny01.gnilink.net...

Are you going to be using ISE or Foundation? They are two completely
different software packages. ISE is very similar to the Webpack (another
reply you received describes the differences). Foundation is no longer
supported by Xilinx and is based on third party software. Also
Foundation will not do the newer FPGAs and ISE will not do the older

FPGAs.

Dave wrote:

I am just about to go through a 115 page introduction tutorial on the

XCESS

website for using the Xilinx Webpack 4.x edition. However I will be

using

the ISE Foundation 4.x edition and want to know if I am wasting my time
reading the entire Webpack tutorial to learn how to use the ISE

Foundation

edition. I am assuming its all the same, with Webpack just having less
features. Anyone who is familiar with both editions that can let me know

to

go ahead with this or STOP - and find a tutorial at Xilinx instead (I

need

to install the software for their tutes I think) would be much

appreciated.

Initial stages will be purely schematic entry. VHDL will come later.

Regards
Dave

 

[Ken Land]

Jesse,

Thanks for the tips. Turning of rubberbanding is working like a charm.

Also, FYI, Altera online support verified the behavior and submitted an
enhancement request.

I'm happy enough.
Ken

"Jesse Kempa" <kempaj@yahoo.com> wrote in message
news:95776079.0309171039.2e0ba177@posting.google.com...

Ken,

This seems to be an evil of block-based schematic design. The more
traditional blocks that we'd instantiate have a fixed set of ports...
and no need to move connections around. For SOPC-type systems where
peripherals and memory are added (or removed) with a mouse click, it
becomes more difficult.

One trick I use is to highlight an area in the schematic file
containing groups of pins & wires (connected to a block), and then cut
& paste them to a blank area of schematic (for example the SDRAM pins
as a group). Since the sets of IO for some piece of IP such as the
SDRAM controller don't change, any update you do to a Nios/SOPC system
will produce part of the schematic block with the exact same
arrangement of IO ports... after modifying my system (and having the
schematic block updated), I just select (as a group) the original IO
pins, and drag them to connect up to the schematic block.

It seems though, that many folks are steering away from schematic
blocks because of this in complex designs, in favor of hierarchic HDL.
This approach can be taken for Nios designs as our top level (from
SOPC Builder) is in fact an HDL file, but we provide schematic
top-levels in our example designs for clarity & getting started
purposes.

Jesse Kempa
Altera Corp.
jkempa at altera dot com



"Kenneth Land" <kland1@neuralog1.com> wrote in message
news:<vmf84etmtns5a1@news.supernews.com>...
Can anyone tell me how to avoid redoing all the Nios block port
connections
whenever I edit the processor config?

Whenever I add something to the Nios config in SOPC builder and update
the
block, all of my connections are broken and all I know to do is
reconnect
them one at a time manually. This takes quite awhile.

Is there anyway to have the update preserve the existing connections?
It
seems to be based only on physical possition within the graphical editor
which seems strange to me.

Thanks,
Ken

 

[Vaughn Betz]

Now for your second issue: why did your design not work after a smart
recompile? I can think of two possibilities:

1. There is some dangerous timing in your design (race conditions,
asynchronous transfers without handshaking, transfers between clock
domains without timing constraints, etc.). By re-placing and routing
your design, a race condition that was latent may have become a
problem.

Yes, you are right. The clocking is kind of messy in my design, lots
of clock gating and other manipulations. So, I can accept it if the
compiled design never worked, that may even make me feel better: I
really shouldn't do those nasty things on clock.

If I change any logics around cross-clock domain region, clock
generator (not pll), clock pll or even an inverter anywhere, I can
probably accept the fact that re-placing and fitting kill the design.
However, failing after moving a few output pins, which have no timing
constraints at all, is hard to understand.


Yi

Hi Yi,

When you change anything in your design, and you haven't
back-annotated, and aren't using incremental fitting, nothing stops
the compiler from changing the placement and routing a lot. In
general the placement and routing will change a lot, but will still
achieve similar speed and routability -- that's all that matters.

There are many (millions, billions?) of placement and routing
solutions to a given design with similar performance. Unless you do
things to force Quartus to get a very similar place and route after a
design change, your place and route will change a lot, but will be
comparable on all the metrics you care about.

The problem with race conditions are that there are things that you
haven't told Quartus about which will make your design work or not
work. Whether a given placement and routing works in the presence of
race conditions will be random.

Vaughn

 

[Michael Dunbar]

Andrew Paule <lsboogy@qwest.net> wrote in message news:<6E2ab.725$VC1.32489@news.uswest.net>...

What format are they in?

Veribest, *.sbk and *.blk files.

 

[Stan]

Ray Andraka <ray@andraka.com> wrote in
news:3E015446.DA84C8FA@andraka.com:

Never divide by a constant... multiply by its reciprocal! -Stan

Unfortunately this algorithm is rather nasty to do in hardware,
requiring a multiply and divide at each iteration. Methods similar to
CORDIC and to hardware division are easier to implement in a hardware
design.

Kip Ingram wrote:

The general approach to rapidly computing logarithms (used by Henry
Briggs to generate the log tables he published in 1617) is to first
reduce the problem to the computation of the logarithm of a value
very near 1. Then use the power series

log (1+x) = x - x^2/2 + x^3/3 - x^4/4 ......

to get a value of whatever accuracy you need. The "cleverness" is in
how to creatively move the argument near 1.

A full treatment of this is given in _Dead Reckoning - Calculating
Without Instruments_ by Ronald Doerfler (ISBN 0-88415-087-9).

Good luck.

Kip Ingram

--
Get daily news and analysis from the FPGA market for pennies a day.
Subscribe to
The FPGA Roundup today: http://www.KipIngram.com/FPGARoundup.html

--
"John" <john.l.smith@titan.com> wrote in message
news:5b9931fd.0212111542.5d473661@posting.google.com...
"Tim Nicolson" <t.nicolson@signal.qinetiq.com> wrote in message
news:<1037972506.869047@bengal>...
[snip]
The ip algorithm requires that I compute logarithms. This can
prove quite a computationally expensive operation, but I only
need accuracy down to around 4/5 significant figures.
[snip]
This method is inexpensive but gives limited accuracy.
Operations shown below


z = a + b*mant + c*mant^2 + d*mant^3;

if (e ~= 0)
z = z + exp * C1;
end;

This requires 6* and 4+.

Hi Tim,
I don't have anything to add to the existing discussion
of logs (sorry), but if you are evaluating polynomials,
you should be aware of Horner's rule ( a personal favorite ):

a + b*x + c*x^2 + d*x^3 =
( a + x*(b + x*(c + x*d ) ) )

this reduces your 6 mults (??? 7) to 3 (??? 4).

[snip]


Thanks very much for your time.

Tim


--
--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

 

[enq_semi]

Hi Yi,

When you change anything in your design, and you haven't
back-annotated, and aren't using incremental fitting, nothing stops
the compiler from changing the placement and routing a lot. In
general the placement and routing will change a lot, but will still
achieve similar speed and routability -- that's all that matters.

Hi, Vaughn,

I totally agree with what you said above. I am just a little
frustrated when I simply bring one internal node (memory lock
indicator, quite static signal) to one LED on board, without changing
anything else, the compilation result changed from "no timing
violation" to "300,000 timing violations" and the longest datapath
increase from 180ns to 210ns.

One friend suggested to me to increase the clock-to-output time for
all the 5MHz output bus to 200ns (otherwise, Quartus will
automatically use the 40MHz input clock to calculate the tco for the
5MHz output signal). That worked 80% of the time.

Anyway, there seems just too many unrelated issues that can affect the
compilation result.

....... waiting for Quartus II 4.0 ....

Yi

 

[Ray Andraka]

Who said anything about the divisor being a constant?

--
--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

 

[Ray Andraka]

More than you can count on both hands and feet, even if you count in binary


Arnaldo Oliveira wrote:

Hi!

Could someone tell me how many transistors are integrated on the XC3S5000
Spartan-3 device?
Thank You.
Arnaldo.

--

--
--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

 

[Peter Alfke]

I think the answer is " more than 100 million, but less than 300 million".

We are caught between embarrassment: "that's how many we need" and
pride: "that's how good we are, to be able to make and sell that many
for a reasonable price".

An then there still are some people who really and seriously (!) think
they can calculate device reliability and MTBF from the total number of
transistors. These guys do not seem to die out, even though we have told
them, and proven to them, again and again, that such calculations are
utter nonsense.

So Ray is right, you would need another seven or eight fingers...
Peter Alfke
========================
Ray Andraka wrote:

More than you can count on both hands and feet, even if you count in binary


Arnaldo Oliveira wrote:

Hi!

Could someone tell me how many transistors are integrated on the XC3S5000
Spartan-3 device?
Thank You.
Arnaldo.

--

--
--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