EDK : FSL macros defined by Xilinx are wrong

[Bakul Shah]

On 9/18/11 10:02 PM, Andrew Reilly wrote:

On Sun, 18 Sep 2011 18:26:45 -0700, Bakul Shah wrote:

On 9/18/11 12:38 AM, nmm1@cam.ac.uk wrote:
In article<4E74F69C.5080009@bitblocks.com>,
Bakul Shah<usenet@bitblocks.com> wrote:

I have not seen anything as elegant as CSP& Dijkstra's Guarded
commands and they have been around for 35+ years.

Well, measure theory is also extremely elegant, and has been around for
longer, but is not a usable abstraction for programming.

Your original statement was
Despite a lot of effort over the years, nobody has ever thought of a
good way of abstracting parallelism in programming languages.

I gave some counter examples but instead of responding to that, your
bring in some random assertion. If you'd used Erlang or Go and had
actual criticisms that would at least make this discussion interesting.
Ah well.

I've read the language descriptions of Erlang and Go and think that both
are heading in the right direction, in terms of practical coarse-grain
parallelism, but I doubt that there is a compiler (for any language) that
can turn, say, a large GEMM or FFT problem expressed entirely as
independent agents or go-routines (or futures) into cache-aware vector
code that runs nicely on a small-ish number of cores, if that's what you
happen to have available. It isn't really a question of language at all:
as you say, erlang, go and a few others already have quite reasonable
syntaxes for independent operation. The problem is one of compilation
competence: the ability to decide/adapt/guess vast collections of
nominally independent operations into efficient arbitrarily sequential
operations, rather than putting each potentially-parallel operation into
its own thread and letting the operating system's scheduler muddle
through it at run-time.

Now I am not sure what Nick meant by "abstracting parallelism".
I asked but he didn't clarify. I thought he meant "expressing the
essential properties of parallelism". And here I think CSP/guarded
commands do an excellent job). I think you are talking about is
"placement" -- mapping an N-parallel algorithm to a smaller number
of cores and in general making optimum use of available resources.
But these are implementation issues, not abstraction ones. I agree
that compilers have a long way to go.

Once easy to use parallel languages become widely available and we
gain some experience I am hoping that
a) better implementations will follow.
b) we will find ways to extract parallelism in the language itself
c) they will lead to much *simpler* h/w structures. Seems to me a
lot of the h/w complexity is due to wanting to dynamically extract
parallelism.

 

[Nico Coesel]

Jon Elson <elson@pico-systems.com> wrote:

Nico Coesel wrote:



IMHO this is the wrong solution. Actually it is not a solution at all.
You really should get in touch with someone who has experience in this
field in order to solve the problem at the root.

You have to understand this is a REALLY small business. I have an
old Philips pick & place machine in my basement, and reflow the boards
in a toaster oven, with a thermocouple reading temperature of the boards.
I can't afford to have a $3000 a day consultant come in, and they'd just
laugh when they saw my equipment.

In that case you'll have to experiment yourself or have the boards
produced by an assembly house. Soldering lead-free is more difficult
to get right because the temperature tolerances are much narrower.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

In article <j564dn$1l6$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

In comp.arch.fpga Andrew Reilly <areilly---@bigpond.net.au> wrote:

Despite a lot of effort over the years, nobody has ever thought of a
good way of abstracting parallelism in programming languages.

That's not really all that surprising though, is it? Hardware that
exhibits programmable parallelism has taken many different forms over the
years, especially with many different scales of granularity of the
parallelisable sequential operations and inter-processor communications,

Yes, but programs tend to follow the mathematics of matrix algebra.

A language that allowed for parallel processing of matrix operations,
independent of the underlying hardware, should help.

There are several. APL is one (very limited) classic, but there
were quite a lot of engineering languages in the 1960s and 1970s,
and then there are Matlab and modern Fortran. None of those specify
parallel processing, but all allow it.

Now, all of those abstract only dense, rectangular matrix algebra;
sparse is a lot trickier, and others are worse still.

The entire issue of parallelism is essentially orthogonal to the
sequential Turing/von-Neuman model of computation that is at the heart of
most programming languages. It's not obvious (to me) that a single
language could reasonably describe a problem and have it map efficiently
across "classical" cross-bar shared memory systems (including barrel
processors), NuMA shared memory, distributed shared memory, clusters, and
clouds (the latter just an example of the dynamic resource count vs known-
at-compile-time axis) all of which incorporate both sequential and vector
(and GPU-style) resources.

Well, part of it is that we aren't so good at thinking of problems
that way. Us (people) like to think things through one step at a
time, and von-Neumann allows for that.

That is the problem. I disagree that parallelism is orthogonal to
the serial Von Neumann model, because there are several forms of
parallelism that don't match that and some that essentially require
it (in both cases, even just compared with functional).


Regards,
Nick Maclaren.

 

In article <9do0nhF1s4U1@mid.individual.net>,
Andrew Reilly <areilly---@bigpond.net.au> wrote:

I've read the language descriptions of Erlang and Go and think that both
are heading in the right direction, in terms of practical coarse-grain
parallelism, ...

What is currently called coarse-grain parallelism isn't really an
abstraction in terms of a programming interface. All of the forms
I have seen are merely APIs for a collection of communicating
sequential processes, for the few current communication techniques.
The theoretical work isn't one, either, and is a mathematical model
for reasoning about such systems. At BEST, it is the assembler of
parallelism.

A relevant abstraction would be comparable to procedures or arrays,
both of which predate computing but have been incorporated very
sucessfully as a programming model. 'Futures' are a possibility,
but aren't new and didn't get very far in their previous incarnations.

I don't think that ANY form of communicating sequential processes
can be made into even a decent programming model, as it is far too
close to the (current) hardware and far too far away from the
mathematical formulation of real problems.

Someone (maybe you?) mentioned networks and trees. I fully agree,
and regard them as VERY badly handled by any current programming
language I know of, serial or otherwise. I have some ideas on how
to improve matters, but the extra generality makes the problem vastly
more complicated.


Regards,
Nick Maclaren.

 

[Andrew Reilly]

On Mon, 19 Sep 2011 08:01:52 +0100, nmm1 wrote:

I have some ideas on how to improve matters, but the extra generality
makes the problem vastly more complicated.

I think that is a large part of the "rub": we're in what might be a local
minimum (or at least inflection) of the language space, and the trouble
with heading in what seems to be the right direction is that performance
gets significantly worse until the runtime/compilation systems are a
*lot* more sophisticated than we have at the moment. So we don't go
there, and they don't get developed.

Someone is probably working on the right answer, somewhere, already. If
I can imagine it then brighter people than me are bound to be giving it a
go: my first rule of the internet...

Cheers,

--
Andrew

 

[Brian Drummond]

On Sun, 18 Sep 2011 17:18:53 -0500, Jon Elson wrote:

Jon Elson wrote:

Hmmm, one additional tidbit. Some boards reflowed at the same time have
been stored in a lab environment. These boards in question were stored
in my basement for six months. The lab env. boards show no sign of the
whiskers. Conditions in my basement are not bad at all, but it is
likely more humid down there than in the lab.

You mention humidity, but not temperature. Is there a possibility that
the temperature fell below 10C during that storage period?

http://en.wikipedia.org/wiki/Tin_pest#Napoleon.27s_buttons

- Brian

 

In article <9dol8bF5p6U1@mid.individual.net>,
Andrew Reilly <areilly---@bigpond.net.au> wrote:

I have some ideas on how to improve matters, but the extra generality
makes the problem vastly more complicated.

I think that is a large part of the "rub": we're in what might be a local
minimum (or at least inflection) of the language space, and the trouble
with heading in what seems to be the right direction is that performance
gets significantly worse until the runtime/compilation systems are a
*lot* more sophisticated than we have at the moment. So we don't go
there, and they don't get developed.

Actually, no. That's true of a lot of proposals, but I regard them
as demented - because they are almost always assuming improvements
in the solution to known intractable problems. My ideas are very
different, but would involve programmers changing their approaches
to mapping mathematics into code! I don't think that efficiency is
necessarily a problem.

Someone is probably working on the right answer, somewhere, already. If
I can imagine it then brighter people than me are bound to be giving it a
go: my first rule of the internet...

It is vanishingly unlikely that there IS a 'right answer', any more
than there is for serial languages. Also, I don't believe in simple
solutions to known intractable problems, though they do occasionally
arise.


Regards,
Nick Maclaren.

 

[Morten Leikvoll]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
news:j575ot$d20$1@dont-email.me...

On Sun, 18 Sep 2011 17:18:53 -0500, Jon Elson wrote:

Jon Elson wrote:

Hmmm, one additional tidbit. Some boards reflowed at the same time have
been stored in a lab environment. These boards in question were stored
in my basement for six months. The lab env. boards show no sign of the
whiskers. Conditions in my basement are not bad at all, but it is
likely more humid down there than in the lab.

You mention humidity, but not temperature. Is there a possibility that
the temperature fell below 10C during that storage period?

http://en.wikipedia.org/wiki/Tin_pest#Napoleon.27s_buttons

I guess stress on the pads are also a parameter that may influence growth of
whiskers..

 

[Jon Elson]

On 09/19/2011 03:28 AM, Nico Coesel wrote:

In that case you'll have to experiment yourself or have the boards
produced by an assembly house. Soldering lead-free is more difficult
to get right because the temperature tolerances are much narrower.

I've been doing lead-free boards on my commercial products, and after
some trouble, mostly with solder wetting, I now have the process working
quite well. But, the boards have to be made with FR-406 and lead-free
finish to make it work.

Since the research products I make are intended to have a much longer
operating life (like 20+ years) I have been making them with Sn/Pb
solder, but components are very hard to get in this finish. Anyway,
these existing boards were not made for lead-free temperatures, and so
I CAN'T run them at 250 C or they will likely delaminate.

Jon

 

[Jon Elson]

On 09/19/2011 05:33 AM, Brian Drummond wrote:

On Sun, 18 Sep 2011 17:18:53 -0500, Jon Elson wrote:

Jon Elson wrote:

Hmmm, one additional tidbit. Some boards reflowed at the same time have
been stored in a lab environment. These boards in question were stored
in my basement for six months. The lab env. boards show no sign of the
whiskers. Conditions in my basement are not bad at all, but it is
likely more humid down there than in the lab.

You mention humidity, but not temperature. Is there a possibility that
the temperature fell below 10C during that storage period?

Nope, no way. This is a living space, and I am in there for several

hours every day. Temps below 20 C might be possible, but not below
that.

Jon

 

[Rob Doyle]

On 9/18/2011 3:31 PM, Nico Coesel wrote:

Jon Elson<elson@pico-systems.com> wrote:

Jon Elson wrote:

Hmmm, one additional tidbit. Some boards reflowed at the
same time have been stored in a lab environment. These boards
in question were stored in my basement for six months. The lab env. boards
show no sign of the whiskers. Conditions in my basement are
not bad at all, but it is likely more humid down there than
in the lab. So, I guess this means don't store lead-free
boards in humid conditions.

IMHO this is the wrong solution. Actually it is not a solution at all.
You really should get in touch with someone who has experience in this
field in order to solve the problem at the root.

There is a really good reason why the Aerospace and Military have been
exempted from the ROHS mandates. That's because under extreme
environments (maybe including humid basements), ROHS doesn't work
well. It is well known that it grows Tin Whiskers.

It is a real PITA for those industries because suppliers would rather
drop the old parts. Every component gets a review by our
manufacturing experts to determine if it compatible with our soldering
processes. Sometimes we go to the trouble of 're-balling' parts to get
the 'right' kind of solder that is known to work. Sometimes they just
reject the component outright and tell us to find another one...

By all means you should understand your issue - maybe there is room for
some process improvement. I'm just suspicious that there is no
solution, yet.

Rob.

 

[F M]

On Sep 23, 3:21 am, Charlie <charlieD...@verEYEzon.net> wrote:

On 9/22/2011 4:53 PM, Kevin Neilson wrote:

I used to use a really nice, simple, browser-based timing diagram
editor, and now I've forgotten the name and URL of this tool.  Does
anybody know which one I'm talking about?  There was a text window to
enter signal names and values as strings of text, like 10xz01C00, and
then the waveforms would show up on the web page.  You could save a
diagram and get the URL so you could use the URL to retrieve it.  I
think it was something written by some guy in his spare time.

Probably not the one you mean but google has something like what you
want in their code section:

http://code.google.com/p/wavedrom/

Charlie

I don't know about the tool you are speaking about but the following
FONTS
http://www.pcserviceselectronics.co.uk/fonts/
are useful when making documentation.
Very simple, just use those fonts in the wordprocessor.

Fabio

 

[Paul Colin Gloster]

Scott Michel <scooter.phd@gmail.com> sent:
|--------------------------------------------------------------------------|
|"On Sep 14, 2:06 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: |
|> > 6.  A new language with APL-like semantics would allow programmers to|
|> > state their wishes at a high enough level for compilers to determine |
|> > the low-level method of execution that best matches the particular |
|> > hardware that is available to execute it. |
|> |
|> APL hasn't been popular over the years, and it could have done |
|> most of this for a long time.  On the other hand, you might look |
|> at the ZPL language.  Not as high-level, but maybe more practical." |
|--------------------------------------------------------------------------|

Languages can allow compilers to optimize in a way which compilers
do not bother to do. That was true of APL and other languages.

|----------------------------------------------------------------|
|"ACM killed off SIGAPL about 5-6 years ago. Sorry to see it go."|
|----------------------------------------------------------------|

SIGAPL exists. In what way was SIGAPL "killed off"?

|-----------------------------------------------------------------------|
|"Have a look at the DARPA HPCS languages, notably, Chapel, Fortress and|
|X10. Not entirely sure about their respective statuses, but they were |
|an attempt in the HPC arena to raise the level of abstraction. |
| |
| |
|-scooter" |
|-----------------------------------------------------------------------|

Someone of Oracle authored an article in "The Journal of the ACM" or in
"The Communications of the ACM", mainly re replacing efficient Fortran
code with fewer lines of Fortran with "only" a drop in performance of
circa 100%. Fortress and circa two other languages (maybe Chapel and
Fortress) were briefly mentioned.

In a manuscript by myself which is currently under review, I mention
Fortress (and Fortran). In some drafts of the manuscript I mentioned
part of Fortress which is less abstract for efficiency (or maybe
at a higher level and less efficient). I edited that observation out
before submitting the manuscript to the journal because of a space
constraint and the focus of the manuscript is something else.

The edited Fortress section still shows that the idea that the notion
that high abstraction is deployed in Fortress is laughable.

Sincerely,
Paul Colin Gloster

 

[Michael Seery]

Thanks for your help. Turns out, all the libraries were spot-on, and it didn't make a difference whether it was attached globally or locally.
Called Aldec, took an hour. Made a newbie mistake. Here's the details, for anyone with the same problem later:
I was including the EDIF (.edn) file in the compilation. The EDIF is for skipping synthesis and has nothing to do with compiling. It was automatically generated by the CoreGen Wizard, and I had just assumed it was a dependency for the FIFO. The compiler was allowing it, but in elaboration, it barfed.. All I had to do was exclude the .edn file from compilation, and everything worked.

Thanks again.

 

[Uwe Bonnes]

Elam <elampooranan@gmail.com> wrote:

I understand that the price depends on the volume etc
but I would like to know the per unit price of Virtex 7 FPGA..

Any guesses..

Search for XC7V on www.findchips.com.

And better sit down before checking...

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

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

 

[Ed McGettigan]

On Mar 28, 10:31 am, Elam <elampoora...@gmail.com> wrote:

I understand that the price depends on the volume etc
but I would like to know the per unit price of Virtex 7 FPGA..

Any guesses..

Thanks
Elam.

There are too many variables (device, package, speed grade, volume,
delivery date, etc..) involved in pricing for any simple answer.
Contact your local Xilinx sales rep and they would be happy to sit
down and discuss your needs and come up with the right pricing that
matches your situation.
http://www.xilinx.com/company/contact/sales-reps.htm

Using online pricing data for 1-10 parts today will not be reflective
of 1K-10K pricing 18 months from now.

Ed McGettigan
--
Xilinx Inc.

 

[Uwe Bonnes]

Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote:

Elam <elampooranan@gmail.com> wrote:

I understand that the price depends on the volume etc
but I would like to know the per unit price of Virtex 7 FPGA..

Any guesses..

Search for XC7V on www.findchips.com.

No online availability for now. Prices last time I checked was up to 50 k$...

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

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

 

[daniel.kho]

Sorry I came in late for this one.

`timescale 1ns/1ns

module simulatedUartTransmitter(output reg TxD);
time bitTime;
//
task setBitTime(input time newBitTime);
bitTime = newBitTime;
endtask

task sendChar(input [7:0] char);
begin
// send start bit
TxD = 0;
// send eight data bits, LSB first
repeat (8) begin
#(bitTime) TxD = char[0];
char = char >> 1;
end
// send stop bit
#(bitTime) TxD = 1;
#(bitTime);
end
endtask
//
initial TxD = 1; // line idles in "Mark" state
//
endmodule

module justTryThisOne;
// connections
wire serial_TxD;
// stimulus generator instance
simulatedUartTransmitter txGenerator(.TxD(serial_TxD));
//
// There's no DUT in this example, but you can still
// see the signal generator at work.
//
// code to generate some stimulus
initial begin
txGenerator.setBitTime(104000); // 9600Bd, roughly
#1_000_000; // idle awhile before starting
txGenerator.sendChar("h"); // ask the sig-gen...
txGenerator.sendChar("i"); // ...to send some data
txGenerator.sendChar("!"); // ...at our request
#1_000_000; // idle awhile at the end
end
endmodule

I'm still quite new to VHDL external names. But I thought this is alread
possible with VHDL-2008?

The simulatedUartTransmitter just looks like a package to me, with a fe
procedures:

library ieee; use ieee.std_logic_1164.all;
package uartPkg is
type simulatedUartTransmitter is protected
procedure setBitTime(newBitTime:in time);
procedure sendChar(char:in character);
end protected simulatedUartTransmitter;

signal TxD:std_ulogic;
shared variable uartTx: simulatedUartTransmitter;
end package uartPkg;

package body uartPkg is
type simulatedUartTransmitter is protected body
variable bitTime:time;
procedure setBitTime(newBitTime:in time) is begin
bitTime:=newBitTime;
end procedure setBitTime;

procedure sendChar(char:in character) is begin
/* use wait statements to wait on bitTime. */
...
end procedure sendChar;
end protected body simulatedUartTransmitter;
end package body uartPkg;

/* The testbench. */
library ieee; use ieee.std_logic_1164.all;
entity justTryThisOne is end entity justTryThisOne;

architecture noTestbenchInst of justTryThisOne is
signal serial_TxD: std_ulogic;
alias txGenerator is <<variable @work.uartPkg.uartTx
@work.uartPkg.simulatedUartTransmitter>>;
begin
tester: process is begin
txGenerator.setBitTime(104000);
wait for 1 us;
txGenerator.sendChar('h');
txGenerator.sendChar('i');
txGenerator.sendChar('!');
wait for 1 us;
end process tester;
end architecture noTestbenchInst;

I haven't tried this with any simulator, but it might just work.

regards, daniel



---------------------------------------
Posted through http://www.FPGARelated.com

 

[daniel.kho]

One question though: if the task sendChar is called concurrently from
different procedural blocks in a way that the calls are overlapping, I
think the result would be a great mess (I am saying this as a not s
great
lover of how Verilog works).

Is there a simple way to deal with collisions like that? Or will the
simplicity be lost then for the most part?

That's the reason why we have to use protected types to acces
methods/functions directly from a package or another entity.
Peter Ashenden's book explains well...

regards, daniel



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Daniel Kho]

On Friday, May 4, 2012 3:39:27 AM UTC+8, daniel.kho wrote:

/* The testbench. */
library ieee; use ieee.std_logic_1164.all;
entity justTryThisOne is end entity justTryThisOne;

architecture noTestbenchInst of justTryThisOne is
signal serial_TxD: std_ulogic;
alias txGenerator is <<variable @work.uartPkg.uartTx:
@work.uartPkg.simulatedUartTransmitter>>;
begin
tester: process is begin
txGenerator.setBitTime(104000);
wait for 1 us;
txGenerator.sendChar('h');
txGenerator.sendChar('i');
txGenerator.sendChar('!');
wait for 1 us;
end process tester;
end architecture noTestbenchInst;

Sorry, I guess serial_TxD should have been:
alias serial_TxD is <<signal @work.uartPkg.TxD: std_ulogic>>;
instead of declared as another signal within the architecture.

This way, you can check/monitor the output of the UART from this same testbench.

-daniel