Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Zoltan Kocsi writes: > In a free-standing environment main() is just a function like any other. > There's nothing special about it. Be careful with this. GCC treats main() specially even for a free-standing target. Your function main() does not compile to a function called main(), but is instead renamed __main() by the compiler. libgcc.a supplies a function called main() which calls your __main(), after calling any static constructors it can find. Often there aren't any in C. libgcc.a's main() also calls atexit() on some targets before calling your __main(). What I'm saying here is that unless you make special arrangements, even in a free-standing environment, a standalone GCC-compiled program will do stuff before reaching what you thought was called main(). -- JamieArticle: 14426
ems@riverside-machines.com.NOSPAM wrote: > i hadn't realised that you could actually *do* anything with Handel-C. > is there a practical mechanism for targetting xilinx? does it work, > how do you do it, how much?? 1) yes, Xilinx and nothing else AFAIK 2) yes 3) there's a good user manual, you just write the code and submit it to the compiler :-) and get ?XNF out of it; not sure about that last bit, but in any case you need the Xilinx P&R tools to do the physical stuff 4) about UKP 2K, but see the website, I think there is a demo version Handel-C website: http://www.embedded-solutions.ltd.uk/ I have no commercial/financial interest in the company Jonathan BromleyArticle: 14427
ems writes: [About Occam, quoting Jonathan Bromley] >> | 1) it was technically competent >> | 2) it was at least a decade ahead of its time >> | 3) it originated in Britain :-) > and, of course: > 4) somebody (a) forgot to patent it, or (b) patented it, and then sold > off the patent without noticing. 5) somebody forgot to (a) promote it properly, (b) develop the language in a useful direction. Unless you count Handel-C of course:-) > i hadn't realised that you could actually *do* anything with Handel-C. > is there a practical mechanism for targetting xilinx? does it work, > how do you do it, how much?? It's very Xilinx oriented -- almost all the demos run on Xilinx chips. In some ways its a problem -- I'm doing exclusively Altera stuff, and the compiler isn't entirely happy with it. It works though. -- JamieArticle: 14428
Jonathan Bromley writes:
> Mainly, the way in which the present release of Handel-C is something
> of a Xilinx bigot, and uses all sorts of weird constructs/pragmas
> that are outside the language proper to control exploitation of
> device features.
I do exclusively Altera stuff, and I totally agree with you. It's not
all that friendly to anyone/thing outside its own narrow vision. Which
is currently much Xilinx + a little Altera and nothing else.
> Not a criticism of the language itself, of course.
> If I were being cynical I could suggest that it reflects
> commercialisation of the language at rather too early a stage....
Commercialisation _per se_ is not a problem. It's just selling what you
have. But I do think that the way it's being done is unfortunately
narrowly focussed. (Does this mean we agree?)
> My most serious concern about the *language* is the irrevocable
> one-to-one relationship between assignments and clock cycles. I know
> why this was done, and I know it is often convenient, but there are
> occasions when a "non-clocking assignment" would make for much clearer
> expression of certain problems. VHDL deals with this issue by
> distinguishing between signals and variables.
The timing thing as really handy. Surprisingly so. At first I didn't
like it because of its apparent inflexibility. But since it was pointed
out as a _feature_, I've really found ways to use it. A lot of stuff,
including I/O interfacing and internal dataflow stuff is so much more
_succinct_ because of the implied timing relationships.
The 1-1 relationship is not irrevocable. I know there are ways to
remove it and remain compatible. Retiming optimisations can be very
effective, more so with relaxed timing constraints on "untimed"
variables and channels. Imagine treating a channel as a FIFO where the
compiler determines the optimal low & high water marks (often the same)
and optimal forwarding paths. Imaging analysing data flow through timed
and/or untimed variables to get the real flow relationship, and
optimising that. That's _way_ better than you'll ever get with VHDL.
I have heard there is some research on the clever retiming stuff, but
I'm not sure I believe it.
> There is also a practical problem about the semantics of channels
> in a clocked (as opposed to asynchronous) environment. One
> Handel-C guru (names withheld to protect the guilty :-) ) has told me
> that he tends to use shared variables in preference to channels
> to avoid the extra clock cycle overheads. If he had a grave, I
> suspect Tony Hoare would be turning in it...
I suspect I know who you mean :-) The irony is that _assigning_ shared
variables introduces the same clock cycle overheads. (Communication and
assignment as very similar in Handel-C). And it totally destroys any
semblance of modularity.
To really remove those cycle overheads, you have to expose and pass
_internal expressions_ from one module to another. That is very messy
indeed. And it doesn't always work do to mutual recursion problems.
Well, unless you treat Handel-C as a way to write a netlist :-)
You can think of me as the "Handel-C channel guru". I know how to make
channels do lots of things, and the deep magic of `prialt' which nobody
else uses. They are good for modularity, and something easily missed:
they enforce scalability of your synthesised program.
See it this way: Handel-C forces you to write pipelined data flows. You
connect lots of pipelines together and the overall logic depth stays the
same. In theory (<ahem> ;-), no slowdown.
> As a secondary point, I could raise the limitations of Handel-C when
> addressing asynchronous design (for which Occam offers great potential
> benefits, as you are aware I'm sure!) and/or multiple clock domains
> on the same device. And I haven't yet understood how it deals with
> design/library maintenance issues in the way that VHDL does, although
> this may be because I haven't got to grips with the details yet.
Let's see :-)
My current program runs on an Altera Flex10K50GC403-3, has two clock
domains and a variety of fascinating asynchronous signals with awkward
timing constraints. The two clocks run at 33MHz and 16.5MHz, locked
together. It does various kinds of packet multiplexing, rewriting and
prioritising, has lots of internal pipelines, loosly coupled (random
bubbles flowing through), talks to PCI via an AMCC chip and to two
100Mbit DS-Link interfaces. The AMCC and DS-Link chips are connected
directly to the FPGA, and the I/O interfacing is written in Handel-C.
My previous program had _three_ clock domains, at 33MHz, 16.5MHz and
~10MHz (variable, PLLed to Ethernet data). It used asynchronous FIFOs
written in Handel-C (well sort of, not the sort of Handel-C they want me
to scare newbies with :-). The Handel-C code interfaced directly with
an Ethernet 10Mbit physical layer chip (Handel-C implemented the MAC
layer -- framing, retransmissions, CRC etc.), and the AMCC chip for a
PCI interface.
{ Consultancy charges on request ;-) }
The library issues do suck, but you can work around the problems by
being organised with namespaces, good use of header files etc. CPP is a
saviour here. It is said that the libraries issues will be addressed
for the next major release.
>> I find Handel-C's limitations very frustrating, but with experience
>> I've found ways of doing things that turn out nicely in the end.
> I defer to your experience. I haven't yet used Handel-C on a "live"
> project. Certainly I've been very impressed with some of the stuff
> that your hardware-compilation group has done with it.
-- Jamie
Article: 14429
Does anybody know about memory compilers?
Any info will be high appreciated.
--
Romanovsky Sergey phone : 38044 241 7115
Design Manager fax : 38044 241 7031
email : thesys@carrier.kiev.ua
WWW entry : http://www.ln.com.ua/~thesys
Address : JV "THESYS-Mikropribor"
Polytekhnicheskaya Str.33
252056 Kiev,Ukraine
Article: 14430Duck Foot wrote in message <36B16A5A.5110E9F2@hotmail.com>... > Textbooks tell how to get rid of static hazards inherent in a sum of >products network. They say the hazard comes from transitions between >neighboring product terms, and can be eliminated by adding redundant >implicants. > > Do we also call the transitions between two apart product terms, >e.g. diagonally positioned ones, hazard? How can I eliminate glitches >born of this kind of network? - In this case circling 0's to eliminate >0-hazard also results in diagonal configuration. > Are you using synchronous logic? If so, then the hazard conditions probably don't matter anyway. If you're using the output of your circuit to clock a flip-flop or something, then the hazards are important. In these cases the redundant implicants work really great. If you're using the redundant implicants technique, then you have to check that the inputs will change as expected. All that they're saying is that certain transitions on the input will generate momentary glitches on the output of the circuit. If I understand what you're saying about 'diagonal' terms, then you have to check to see if your inputs will every change under the 'diagonal' conditions. If so, then you have to add a product term to eliminate them. Wade Peterson Silicore Corporation http://www.silicore.net/Article: 14431
Hrvoje Niksic wrote in message <87socun7jr.fsf@pc-hrvoje.srce.hr>... >"BuckSavage" <wbuckley@transdyn.com> writes: > >> I do not have a problem with the use of the given construction, just >> a problem with programmers who think that such a construction is an >> absolute must. The fact that I can compile and successfully execute >> a program which uses the construction "void main()" is sufficient >> reason for me to do so. > >If you compile and successfully execute a program that passes a >different number of arguments to qsort(), will it be the sufficient >reason to do so? > >Just like qsort(), int main() is an interface. By not abiding to the >rules, you are opening a possibility of your program breaking. If the consequence is that data is processed in a manner to which I am agreeable, then, by all means, it will be sufficient reason to use qsort() in a non-standard way. Gaby, you are correct. Also, the int main() motif was in K&R a default condition. William R. BuckleyArticle: 14432
Emmanuel JOLLY wrote: > <snip> > > Sometimes, my design doesn't download from the EPC1 to the ALTERA. If > I look at the signals with an oscilloscope I can see that CONF_DONE is > low and nSTATUS is low also. According to AN59 nSTATUS should be high > to enable the EPC1. As nSTATUS is low, the download process cannot > take place. > > This problem is correlated with the temperature of the device. When > the environnement is warm, the download process takes place but when I > cool down the chip (with a cooling spray) it doesn't download. > > Any ideas?? I have experienced the same (relatively) problem. Our issue was that device operation was not reliable below -20 C. Granted, we were using commerical grade parts and our application requires Industrial temp. I believe that cooling spray (at least the type we use) cools down to ~ -45 C, so that is probably what you are seeing. Unfortunately we were forced into our situation because Altera out and out lied to us about offering the EPF8282 in a 3.3V Industrial version. Two years later in the middle of our final prototype run I had to do 3 masked-gate array conversions (3 designs in one product) just so that we could meet the Indutrial temp requirements of our (military) customer. That incident is also why we don't do any new designs in Altera devices. -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14433
"BuckSavage" <wbuckley@transdyn.com> writes: > >Just like qsort(), int main() is an interface. By not abiding to the > >rules, you are opening a possibility of your program breaking. > > If the consequence is that data is processed in a manner to which I > am agreeable, then, by all means, it will be sufficient reason to > use qsort() in a non-standard way. Ah, an interesting argument. So, have you actually tried it, or is that reserved for void main()?Article: 14434
Jamie Lokier wrote: < detailed and expert response to many of my concerns about Handel-C > <me speaking> > > My most serious concern about the *language* is the irrevocable > > one-to-one relationship between assignments and clock cycles. I know > > why this was done, and I know it is often convenient, but there are > > occasions when a "non-clocking assignment" would make for much clearer > > expression of certain problems. VHDL deals with this issue by > > distinguishing between signals and variables. > > The timing thing as really handy. Surprisingly so. At first I didn't > like it because of its apparent inflexibility. But since it was pointed > out as a _feature_, I've really found ways to use it. A lot of stuff, > including I/O interfacing and internal dataflow stuff is so much more > _succinct_ because of the implied timing relationships. I think you are reading more into my comment than I put there :-) All I meant was that it is sometimes handy to be able to express certain types of logic as a sequence of intermediate calculations even though the result will NOT be pipelined. Particularly true of certain kinds of bit-bashing operations. Without a zero-time assignment statement and intermediate non-physical variables, this is impossible and you must either pipeline or else dream up a combinatorial expression of the problem. I know that this sort of thing is open to abuse and can give the synthesis tool a serious headache, but I still think it would be a nice extension for those who needed it. I am 100% in favour of Handel-C's basic timing model which, as you say, has all sorts of attractive spin-offs. >You can think of me as the "Handel-C channel guru". OK, I'll take you up on that. Can you please show me some kind of timing diagram which would allow me to check that I am right in my beliefs about what happens when you communicate over a Handel-C channel? For the three different scenarios: sender gets there first, target gets there first, both arrive in the same clock cycle. This is something that is rather skated-over in the published documentation. > I know how to make >channels do lots of things, and the deep magic of `prialt' which nobody >else uses. They are good for modularity, and something easily missed: >they enforce scalability of your synthesised program. What's so deep or so magic about prialt? It just sounds sensible to me. I 100% concur with your comment about modularity and scalability. Regards Jonathan BromleyArticle: 14435
In article <36B16A5A.5110E9F2@hotmail.com>, Duck Foot <duckfoot11@hotmail.com> wrote: > Textbooks tell how to get rid of static hazards inherent in a sum of > products network. They say the hazard comes from transitions between > neighboring product terms, and can be eliminated by adding redundant > implicants. > Do we also call the transitions between two apart product terms, > e.g. diagonally positioned ones, hazard? How can I eliminate glitches > born of this kind of network? - In this case circling 0's to eliminate > 0-hazard also results in diagonal configuration. > > Register it, i.e. use synchronous design methods, if you can. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14436
If you can use synchronous design, then this won't matter. For the record, if you have two terms that are not adjacent, at least two inputs must change state to get from the first state to the end state. Depending on the order those states change, you will have a different path through your state map. Unless all the states in any traverse path are the same, AND each possible state transition pair is covered by a common minterm, you can have a hazard. For an asynch state machine, you want all state transitions to be to adjacent states so that you can avoid this type of hazard. It can make it challenging to assign the states. Duck Foot wrote: > Textbooks tell how to get rid of static hazards inherent in a sum of > products network. They say the hazard comes from transitions between > neighboring product terms, and can be eliminated by adding redundant > implicants. > Do we also call the transitions between two apart product terms, > e.g. diagonally positioned ones, hazard? How can I eliminate glitches > born of this kind of network? - In this case circling 0's to eliminate > 0-hazard also results in diagonal configuration. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 14437
Hrvoje Niksic wrote in message <87socuj6hv.fsf@pc-hrvoje.srce.hr>... >"BuckSavage" <wbuckley@transdyn.com> writes: > >> >Just like qsort(), int main() is an interface. By not abiding to the >> >rules, you are opening a possibility of your program breaking. >> >> If the consequence is that data is processed in a manner to which I >> am agreeable, then, by all means, it will be sufficient reason to >> use qsort() in a non-standard way. > >Ah, an interesting argument. So, have you actually tried it, or is >that reserved for void main()? I have not actually tried a non-standard application of qsort() but, my argument is speculative. That is, if I had a reason to do so, and if I knew that the result was desireable, I would use the routine in some non-standard (unexpected) way. My view is that a programmer should have the ultimate choice in the use of software, instead of having to "toe-the-line" in some fashion expected by some other programmer. Software is a tool, and if it can be used to solve some problem, then by all means use it so. It is my observation that those who began this thread of discussion are far too caught up in the formalities of software practice, and that while such formalities can be valid, they are not absolute. It is agility that we should strive for, above all else. William R. BuckleyArticle: 14438
I ported a small schematic-based design to VHDL in order to benchmark
two synthesizers. Here is a summary of the results:
Area (PFU) Speed (MHz)
Schematic 21 95.2
Exemplar 30 75.6
Synplicity(1) 33 57.4
Synplicity(2) 32 67.2
The circuit is a serial link transmitter macro that transmits 33-bit
data words. It has an 8-word input FIFO, 4B/5B encoder, shifter,
and frame synchronizer.
The circuit was targeted for a Lucent Orca 2T04A-3. This is their
"medium" speed grade. It was designed to run at 50MHz (12.5 MHz
serial bit rate).
The VHDL code was simulated using Aldec Active-VHDL before sythesis.
The schematic was entered using Workview Office with my custom "xfunc"
extensions.
You can get Schematic (.pdf), VHDL code, and disassembled (and annotated)
chip files (*.eqn) at
http://www-ese.fnal.gov/eseproj/trigger/synth_ben.zip
Some notes:
(1)(2) One of the strong points of HDL coding is the ability to use
higher-level constructs, and leave the optimization to the software.
This was tested by implementing the FIFO word counter in two different
ways. This is a 3-bit up/down counter that saturates at Count==7.
A 4th bit is used to indicate an overflow- one count past saturation.
Expressed as "high level" concepts this is:
if (Write = '1') then
if (Wc(2 downto 0) < 7) then
Wc(2 downto 0) <= Wc(2 downto 0) + 1;
end if;
else Wc(2 downto 0) <= Wc(2 downto 0) - 1;
end if;
Wc(3) <= Write and Wc(2) and Wc(1) and Wc(0);
Expressed as logic equations this is:
Wc(0) <= (Write and Wc(2) and Wc(1)) or not Wc(0);
Wc(1) <= (Write and Wc(2) and Wc(1))
or (not Write xor Wc(1) xor Wc(0));
Wc(2) <= (Write and Wc(1) and Wc(0))
or (Wc(2) and(Write or Wc(1) or Wc(0)));
Wc(3) <= Write and Wc(2) and Wc(1) and Wc(0);
This should fit in a single Orca PFU and run very fast.
Both Synplicity and Exemplar attempted to implement the high-level
version using Orca carry logic, and this turned out to be the speed
bottleneck for the circuit. Exemplar had a switch to turn off this
"optimization" and produced a pretty good implementation for the circuit.
Synplicity had no such switch. In addition to using the carry logic,
it put the flip-flops in a separate PFU, increasing the delay as well
as size of the circuit. Using the re-coded equations resulted in the
faster time for Synplicity(2).
(3) Synplicity extracted some clock-enables correctly, and extracted
some synchronous set/reset signals, but did this poorly, resulting
in some related functions being spread across multiple PFU when they
should have been grouped together. It did not attempt to use the
Orca FE-Mux feature, which would have made a significant improvement.
(4) Exemplar used the FE-mux feature well, but in some cases it
substituted it for clock-enable, resulting in some extra routing
resources being used, but no measurable size or performance penalty.
It also used CE correctly most of the time, however it botched it
where several signals should have used the same CE, but the signals
were aliased, causing related functions to not be mapped to the
same PFU.
(5) Both synthesizers inferred memory, however, Synplicity
put useless tristate buffers between the memory outputs and
flip-flops resulting in 5 extra PFUs and extra delay. This
was the timing bottleneck for the faster synplicity version.
(6) Exemplar preserved many signal names. On others it added
some extra postfixes like "_int" or "_dup". Synplicity also
preservered some signal names, but added "Z0Z" to most signal
names. This made many signal names difficult to recognize.
See the disassembled chip files for examples.
Article: 14439Hi, I've been researching reconfigurable computing for an article, and I have found some good explanations of how it works. What I lack is a solid analogy to give to other people to help them understand how it works and how it's an improvement over what we had before. Something like general purpose computing is like a Yugo, and reconfigurable computing like a 'Vette -- something that explains why it's better. Has anyone heard such an analogy that explains this concept to people like me who use computers but don't know how to make them? Any help would be appreciated. Thanks!Article: 14440
An update on the timing front: The results below were a fake comparison since I'd set the PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem & forgot to turn it backlon for the trial run. > o Final results +/-: After running the respective EDIF files through > the Xilinx tools with no timing constraints Synplify had these > differences: > Avg Conn delay : +4%. > Max pin delay: -25%. > Avg delay on 10 worst: -10%. With this flag unset Synplify came out 1-2% ahead. I got the same 30-50% differences between the predicted & actual timngs on a constrained P&R run. Looking at it more closely it turns out that due the very, very large fanouts in my trial design Routing delays were dominating to a huge extent and the Synplify route timings didn't allow for designs as stupid as this! Interestingly those nice Synplicity people have put the timing stuff in text files so that I could, in theory, modify the routing delay multiplier function(s). With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with Spectrum but you have to pay a lot extra, I think another 3K UK Pounds. Not being able to use both in the same design with Synplify is not a problem since I can compile my Verilog & VHDL separately and get NGDBUILD to merge them.Article: 14441
An update on the timing front: The results below were a fake comparison since I'd set the PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem & forgot to turn it backlon for the trial run. > o Final results +/-: After running the respective EDIF files through > the Xilinx tools with no timing constraints Synplify had these > differences: > Avg Conn delay : +4%. > Max pin delay: -25%. > Avg delay on 10 worst: -10%. With this flag unset Synplify came out 1-2% ahead. I got the same 30-50% differences between the predicted & actual timngs on a constrained P&R run. Looking at it more closely it turns out that due the very, very large fanouts in my trial design Routing delays were dominating to a huge extent and the Synplify route timings didn't allow for designs as stupid as this! Interestingly those nice Synplicity people have put the timing stuff in text files so that I could, in theory, modify the routing delay multiplier function(s). With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with Spectrum but you have to pay a lot extra, I think another 3K UK Pounds. Not being able to use both in the same design with Synplify is not a problem since I can compile my Verilog & VHDL separately and get NGDBUILD to merge them.Article: 14442
An update on the timing front: The results below were a fake comparison since I'd set the PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem & forgot to turn it backlon for the trial run. > o Final results +/-: After running the respective EDIF files through > the Xilinx tools with no timing constraints Synplify had these > differences: > Avg Conn delay : +4%. > Max pin delay: -25%. > Avg delay on 10 worst: -10%. With this flag unset Synplify came out 1-2% ahead. I got the same 30-50% differences between the predicted & actual timngs on a constrained P&R run. Looking at it more closely it turns out that due the very, very large fanouts in my trial design Routing delays were dominating to a huge extent and the Synplify route timings didn't allow for designs as stupid as this! Interestingly those nice Synplicity people have put the timing stuff in text files so that I could, in theory, modify the routing delay multiplier function(s). With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with Spectrum but you have to pay a lot extra, I think another 3K UK Pounds. Not being able to use both in the same design with Synplify is not a problem since I can compile my Verilog & VHDL separately and get NGDBUILD to merge them.Article: 14443
On Fri, 29 Jan 1999 22:05:42 GMT, husby@fnal.gov (Don Husby) wrote: <snip> > In addition to using the carry logic, >it put the flip-flops in a separate PFU, increasing the delay as well >as size of the circuit. Using the re-coded equations resulted in the >faster time for Synplicity(2). Does really the synthesizer provide any information about where to place the flip-flops? From my experience the synthesizer only produces a netlist with primitives or macros. Then it is up to the placer to place the primitives/macros. I might be wrong... it has happened before :) / Jonas ThorArticle: 14444
An update on the timing front: The results below were a fake comparison since I'd set the PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem & forgot to turn it backlon for the trial run. > o Final results +/-: After running the respective EDIF files through > the Xilinx tools with no timing constraints Synplify had these > differences: > Avg Conn delay : +4%. > Max pin delay: -25%. > Avg delay on 10 worst: -10%. With this flag unset Synplify came out 1-2% ahead. I got the same 30-50% differences between the predicted & actual timngs on a constrained P&R run. Looking at it more closely it turns out that due the very, very large fanouts in my trial design Routing delays were dominating to a huge extent and the Synplify route timings didn't allow for designs as stupid as this! Interestingly those nice Synplicity people have put the timing stuff in text files so that I could, in theory, modify the routing delay multiplier function(s). With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with Spectrum but you have to pay a lot extra, I think another 3K UK Pounds. Not being able to use both in the same design with Synplify is not a problem since I can compile my Verilog & VHDL separately and get NGDBUILD to merge them.Article: 14445
> I was going to say humility and compliments generally work wonders > in receiving off-beat replies, but it seems you are responding to your > post more than anyone else! Thanks for the tip... I was adding new information that I discovered in my researching the problem. I thought that was kind of obvious ;-) Anyway, thanks to those who gave 'helpful' answers, I believe I've identified what the SIMMs really are. They still don't work in my system, and I don't know why, but at least I do know what they are... AustinArticle: 14446
Dave Fuhriman wrote: > Hi, I've been researching reconfigurable computing for an > article, and I > have found some good explanations of how it works. What I > lack is a > solid analogy to give to other people to help them > understand how it > works and how it's an improvement over what we had before. > Something > like general purpose computing is like a Yugo, and > reconfigurable > computing like a 'Vette -- something that explains why > it's better. Has > anyone heard such an analogy that explains this concept to > people like > me who use computers but don't know how to make them? Any > help would be > appreciated. Thanks! Dave, you started the car analogy...It's like opening the garage and saying: It's sunny and warm today, and I'm going to see my girlfriend: Be a convertible! Next day: I have to take stuff to the dump: Be a station wagon! Next day, when stuck in the muck: Have 4-wheel drive! Next day trying to park: Be a foot shorter! Late at night: Have reclining seats. The rest is only limited by your imagination... Peter Alfke, Xilinx ApplicationsArticle: 14447
This is a multi-part message in MIME format. --------------74D4A789F211F38FE5728856 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello rick.... the restricted license comes with the price of the HOT2 Development System $695 the full LogiCORE PCI32 license from Xilinx is $8895 w/ Design Kit -- Best Regards, John Schewel, VP Marketing & Sales Virtual Computer Corp. http://www.vcc.com --------------74D4A789F211F38FE5728856 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Schewel Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: John Schewel n: Schewel;John org: Virtual Computer Corporation adr: 6925 Canby Ave. #103;;;Reseda;CA;91335;USA email;internet: jas@vcc.com title: VP Marketing & Sales tel;work: +1 (818) 342-8294 tel;fax: +1 (818) 342-0240 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------74D4A789F211F38FE5728856--Article: 14448
Duckfoot, No shortcuts come to mind but what I usually do in a case like this is start with the first one. It is often due to simulation vectors that are carelessly placed, such as a signal changing at the same time as a clock. Also, the first several dozen (or several hundred) can all be cause by the same event -- reset. Therefore, sometimes jogging your asynchronous reset signal a few nanoseconds forward or backward in time can eliminate many of these errors and make it a more manageable list to find any that matter. Good Luck --- Keb'm In article <36B16663.92B16DB3@hotmail.com>, Duck Foot <duckfoot11@hotmail.com> wrote: > Hi everyone, > I'm confronting many hold time violations and glitches while > post-synthesis simulation. Since I built the logic with quite high level > > description and the logic is very massive, it looks impossible to debug > them one by one. > Is there any canonical strategy applied to these kind of problems, > or can I ask you for some refernces? > > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14449
While I agree that it does sound like satish is whining or trying to lay blame for why he hasn't gotten started on his project yet, it really is the responsibility of the local reps to keep the customer happy. If they can't help this guy out before he gets frustrated enough to post a message like this, perhaps one of their competitors can... In article <78im3s$q0c$1@noao.tuc.noao.edu>, "Andy Peters" <apeters@noao.edu.NOSPAM> wrote: > satish_me@hotmail.com wrote in message <78bt35$eql$1@nnrp1.dejanews.com>... > >Hello I am a customer from India to Xilinx. I purchased the Xilinx Express > >foundation series long almost 1 month ago. Till now either for installation > >or to tell how to start was not guided by any of the Indian representative. > >Hence it shows the poor service of the Xilinx company in INDIA. Hence I > >appeal to people of India not to go for purchsing the Xilinx products, > which > >suffer from lack of service in Indian region. > > Instead of blaming Xilinx and their reps for lack of support, have you tried > READING THE MANUALS THAT COME WITH THE SOFTWARE? > > ------------------------------------------ > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters@noao.edu > > "In the beginning, there was darkness. And it was without form, and void. > And there was also me!" > -- Bomb #20, John Carpenter's "Dark Star" > > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z