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
Don Husby wrote: > Many people have suggested that a goal > is to compile "dusty-deck" code into FPGAs and capitalize on the > zillions of lines of C that already exist. I think that it's very > unlikely that this is a useful goal. I think most people will be > willing to do substantial work to make their algorithms run > much-much faster. Maya wrote: (paraphrased) > > It would be better to find an old 486 CPU to run some old C code Brad Hutching wrote: (paraphrased) > > If you want to run some old C code then you should design in a > CPU that will run the C real fast. Herman Schmidt wrote: (paraphrased) > Give up hope of running old C code on FPGAs, it is too inefficient Forgive me if I've misquoted y'all but I think this captures the spirit of things. OK I'll bite, and then I promise never to bring it up again. Here are 5 reasons to run C code on FPGA CPUs. This does not address mapping C directly into logic. 1- "The C code doesn't need to run fast" Running legacy code will not generally be an issue of performance. It will be an issue of capability. If you use an FPGA as a microcontroller, the capability to run old C code can enable the system. It may have absolutely nothing to do with speed. This pattern is typical in a system which would use an FPGA for I/O processing, but needs to compute coefficients "once in a while". If you are responsible for accomplishing a task on an FPGA system, building a CPU in the FPGA and running some old C code is not as crazy as it seems. 2- " There may be no CPU available to run required C code" Users of FPGA processors will not have the option of designing in a new CPU chip, or running code on a workstation, they will be charged with porting an application to a collection of FPGAs and memories. If the application requires a CPU running C code, they should be able to do that within the context of the FPGAs. After all, the reason I write code for a 486 is "because I have one", not because it is the fastest or best CPU around. 3- "Porting anything is non-trivial" There is no such thing as a trivial port of working software to another environment/language. The code needs to be debugged, tested and integrated. Automatic translation of single threaded C code into Verilog or VHDL or .XNF would work though. (would that be a C compiler? :) 4- " My brain is too small" In general, the only way to obtain performance with FPGA systems is to pay very close attention to all aspects of the design. Issues include: algorithm selection precision/error analysis math operator implementation pipelining synchronization parallel/serial tradeoffs In my opinion, these issues are best left to a tool set such as a compiler. The compiler can apply the accumulated knowledge of thousands of people to map a computational requirement (read program) into an arbitrary collection of hardware. For example, "C" environments typically have hard wired functions for math. If the program uses sqrt(), what would really happen is you would include "stdmath.h" and get a function optimized for the target FPGA. 5- " C can be efficient for new designs" It is not enough to say that "C" is ill behaved so we can't use it, and must instead use more appropriate languages. Much of the problem with C can be solved by avoiding usage of "hard to map" constructs such as pointers. If C can be used, it must be used, simply because it is the language of the masses. I'm sorry if I sound like a religious zealot here. I actually enjoy coding at the level suggested. But I don't believe "reconfigurable computing" will ever go anywhere without supporting standard computer languages (what's wrong with basic :). By the way, I would really appreciate it if someone could contribute a VHDL version of the original sqrt() program. I would also like to see result of synthesis to an FPGA for both the VHDL and Verilog version. - Brad TaylorArticle: 3076
ear@indirect.com (Eric Rose) wrote: >Has anyone ever gotten LOG/ic PLD Compiler from ISDATA to install? I've >downloaded the english and german versions, and locks up every time. My system >is 486/50, 8 meg ram, 1.2 gig hard drive, Windows 3.1. > >I've tried no expanded, and with expanded, but it always locks up. Changed my >video driver, still lock. > >Thanks, >Eric The following may help, if your mouse hangs up. Open the Windows "control panel", enter the "386 enhanced" section and increase the idle time for COM1 or COM2 from 2 to 4 seconds. Increase the minimum time slice from 20 to 25 msec. Anyway, you downloaded a version of ISDATA's LOG/iC Classic which offers text based entry and does synthesis for PLDs. This evaluation version does not offer simulation. You should have a look at LOG/iC2 from ISDATA. This is a vendor independent tool set for PLDs, CPLDs and FPGAS. It offers a hierachical design entry which is supported graphically, simulation and synthesis. Design entry formats are Boolean equations, functions tables and statemachines. It's also possible to work with the macrogenerator for regular sructures like adders or counters etc. Another entry method is to work with the 74xx TTL library. VHDL is optional. The free of charge LOG/iC2 EVAL supports all 16V8, 20V8 and 22V10. At the moment this version is only available directly from ISDATA. A version for the net is in preparation. I recommend working with this version, since it also offers simulation and provide all the above mentioned features. It runs under Windows 3.1 and also under Windows 95. If you are interested, simply send a mail to isdata@isdata.de and ask for LOG/iC2 EVAL. Regards Ralph RemmeArticle: 3077
>>>>> "BT" == Brad Taylor <blt@emf.net> writes:
In article <3158EB85.A66@emf.net> Brad Taylor <blt@emf.net> writes:
BT> By the way, I would really appreciate it if someone could
BT> contribute a VHDL version of the original sqrt() program. I
BT> would also like to see result of synthesis to an FPGA for both
BT> the VHDL and Verilog version.
Ok. Here is a quick translation that I simulated that seems to work. This is
strictly a behavioral design with no clocks, etc. It is only slightly
longer than the Verilog version. Note that there are several ways to
write this. I also started on a version that used a function instead
of an entity-architecture but posted this one as it most closely resembled
the Verilog & C code that was originally posted. This will not
synthesize under Synopsys. I will post a version of the code with
minor modifications that does synthesize. Note this is written using
the VHDL-87 standard. I don't have access to VHDL-93 (which would
make this example slightly shorter).
================================= VHDL ALERT ==============================
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
entity sqrt is
port(n : in unsigned(30 downto 0);
val : out unsigned(15 downto 0));
end sqrt;
architecture basic of sqrt is
begin
process(n)
variable l2, t, u, v, u2, p : unsigned(30 downto 0);
constant u_1 : unsigned(30 downto 0) := "0000000000000000000000000000001";
begin
if (2 > n) then
val <= n(15 downto 0);
else
l2 := "0000000000000000000000000000000";
t := n;
t := shr(t, "10");
while t > 0 loop
l2 := l2 + 1;
t := shr(t, "10");
end loop;
u := shl(u_1, l2);
v := u;
u2 := shl(u, l2);
while (l2 > 0) loop
l2 := l2 - 1;
v := shr(v, "01");
p := shl(u + u + v, l2);
p := p + u2;
if (p <= N) then
u := u + v;
u2 := p;
end if;
end loop;
val <= u(15 downto 0);
end if;
end process;
end basic;
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
entity tb is
end tb;
architecture test_it of tb is
signal n : unsigned(30 downto 0) := "0000000000000000000000000000000";
signal val : unsigned(15 downto 0);
component sqrt
port(n : in unsigned(30 downto 0);
val : out unsigned(15 downto 0));
end component;
begin
sqrt1 : sqrt port map(n, val);
process
begin
for i in 4 to 50 loop
n <= conv_unsigned(i, n'length);
wait for 100 ns;
end loop;
end process;
end test_it;
configuration TOP of tb is
for test_it
end for;
end TOP;
Article: 3078(Brad Taylor) blt@emf.net wrote: > 1- "The C code doesn't need to run fast" > [...] > 2- " There may be no CPU available to run required C code" > Users of FPGA processors will not have the option of designing > in a new CPU chip, or running code on a workstation, they will be > charged with porting an application to a collection of FPGAs and > memories. Maybe some day, in some universe, some person will design a reconfigurable computer that has no host microprocessor, but will be required to run the unix operating system. Till then, let's concentrate on getting these things to actually do what they are supposed to excel at. When you give me a tool that allows me to efficiently express complex data paths and control logic and compile it so that it fits in an FPGA and runs at reasonable speed, then you can take some time off and start wondering how to compile C for those who want to run MacProject on it. (Note that that tool can be a C-based language if you want, as long as it works well. But if you spend more than 30 seconds in committee debating whether or not to include the := operator because it's not a C standard, then you've already lost my interest.) > 3- "Porting anything is non-trivial" > [...] Yeah. Just try writing a "hello world" for Windows. > 4- " My brain is too small" > In general, the only way to obtain performance with FPGA systems is > to pay very close attention to all aspects of the design. > [...] > In my opinion, these issues are best left to a tool set such as a > compiler. The compiler can apply the accumulated knowledge of > thousands of people to map a computational requirement (read program) > into an arbitrary collection of hardware. This seems a bit contradictory and completely ignores how things really evolve. A) Even the current software (e.g. Xilinx) puts more effort into "automatic tools" than into tools that "pay very close attention to all aspects of the design". This is because the tool writers beleive that the "automatic" market is more profitable. A classic example is when Xilinx first released its PPR tool signaling a new world order of FPGA tools -- it didn't even allow re-entrant routing or guide files. (After all who would want to hand route a few signals and then let the automatic tools do the rest? That's just not how people work is it?) B) Libraries do not evolve into efficient, well designed tool sets. They evolve into things that can be ported to several types of machines and handle several general cases. If you want a 12-bit well optimized square-root function you'll probably have to roll your own, or use the 16-bit function and suffer some loss of optimization. > 5- " C can be efficient for new designs" > It is not enough to say that "C" is ill behaved so we can't use it, > and must instead use more appropriate languages. Is too. :) > Much of the problem > with C can be solved by avoiding usage of "hard to map" constructs such > as pointers. If C can be used, it must be used, simply because it is > the language of the masses. I think you underestimate the masses. It's not really that difficult to learn a new language, especially since you also have to learn a whole new paradigm as well. If C is clumsy in the new paradigm (note that I'm not saying that it is clumsy, only that it could be clumsy) then a new language may make the whole learning process faster. > I'm sorry if I sound like a religious > zealot here. I actually enjoy coding at the level suggested. But I > don't believe "reconfigurable computing" will ever go anywhere without > supporting standard computer languages (what's wrong with basic :). There are several things that may be holding back reconfigurable computing: Lack of good tools, Cost, Lack of real applications, Marketing issues. Certainly, the inability to program in C may be on the list, somewhere near the bottom.Article: 3079
>I am currently using Synopsys / Xilinx and targeting >a 4005 part. I would like to perform post-route timing >simulation of the device. Unfortunately, we have not >purchased VSS (Synopsys Simulator). I would like to >know if anybody out there has used either Model-Technology >or Mentor's Quick-VHDL to do post route timing SIMs w/Xilinx. >I have gotten this to work from the Altera Tools, but >have not figgured it out for Xilinx >Thanks: > Dean S. Susnow > susnow@cle.ab.com I have used the back annotation tool in exemplar (galileo), and performed post route simulation with MTI, using a XILINX 4000 vital library. Exemplar will output a netlist in VHDL, and an SDF file containing delay information. It's possible to read both into MTI (NB use vital 2.2b switch on MTI v4.4J ) and perform simulation. Xilinx vital libraries are available (precompiled) from exemplar. -- ---------------------------------------------------------------------- Jonathan Jenkins- ASIC Design Engineer - FISP Products, Systolic Technology Limited , 10-16 Tiller Road, Docklands, Tel : +44 (0)171 538 5858 LONDON E14 8PX Fax : +44 (0)171 538 2323 email : J.Jenkins@systolic.com FISP = Foundry Independent Standard Product = Synthesizable VHDL Macro *** - Opinions are my own, and unrelated to Systolic Technology - *** ----------------------------------------------------------------------Article: 3080
>>>>> "BT" == Brad Taylor <blt@emf.net> writes:
In article <3158EB85.A66@emf.net> Brad Taylor <blt@emf.net> writes:
BT> By the way, I would really appreciate it if someone could
BT> contribute a VHDL version of the original sqrt() program. I
BT> would also like to see result of synthesis to an FPGA for both
BT> the VHDL and Verilog version.
As I promised, here is the version that can be synthesized under
Synopsys. The only required modification was to add a wait
statement inside the while loops so that these could be implemented
as clocked sequential loops. I also cleaned up the code somewhat
and parameterized it with a generic.
Note that the argument to the shl and shr functions must be converted
into an integer. This is a minor problem because there is no way to
convert a 32-bit unsigned number (unsigned) into a 32-bit signed
number (integer) (it causes a run-time error). That was why I used a
31-bit number as input on my earlier post. There is probably a way
around this but this was a quick hack. It was not an issue in the
circuit I synthesized because I only used a 16-bit input with an 8-bit
output.
I synthesized this (16-bit) for a Xilinx 4010PC84-5. I also verified
the synthesis results by compiling and downloading to our Teramac and
the circuit worked properly. Teramac is very handy for verifying the
output of Synopsys because it is so quick and easy to use.
I also included the results from the Xilinx PPR sqrt.out file. NOTE:
I made no attempt to optimize the synthesis process nor did I suggest
timing for PPR. Timing constraints and optimization parameters have
a HUGE impact on the final circuit. So, interpret these results
accordingly. They probably represent the worst possible outcome.
But hey, if anyone wants to burn some cycles to optimize this...
============================ VHDL ALERT ====================================
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
entity sqrt is
generic(width : integer:=16);
port(clk : in std_ulogic;
n : in unsigned(width-1 downto 0);
val : out unsigned((width/2)-1 downto 0));
end sqrt;
architecture basic of sqrt is
begin
process
variable v, u2, l2, t, u, p : unsigned (width-1 downto 0)
:= (others =>'0');
constant u_1 : unsigned (width-1 downto 0) := (others=>'0');
begin
if (2 > n) then
val <= n((width/2)-1 downto 0);
else
l2 := (others => '0');
t := n;
t := shr(t, "10");
while (t > 0) loop
wait until clk'event and clk = '1';
l2 := l2 + 1;
t := shr(t, "10");
end loop;
u := shl(u_1+1, l2);
v := u;
u2 := shl(u, l2);
while (l2 > 0) loop
wait until clk'event and clk = '1';
l2 := l2 - 1;
v := shr(v, "01");
p := shl(u + u + v, l2);
p := p + u2;
if (p <= N) then
u := u + v;
u2 := p;
end if;
end loop;
val <= u((width/2)-1 downto 0);
end if;
wait until clk'event and clk = '1';
end process;
end basic;
============================== PPR Results =================================
Design Statistics and Device Utilization
----------------------------------------
Partitioned Design Utilization Using Part 4010PC84-5
No. Used Max Available % Used
---------------------------- ------- ------------- ------
Occupied CLBs 236 400 59%
Packed CLBs 129 400 32%
---------------------------- ------- ------------- ------
Bonded I/O Pins: 25 61 40%
F and G Function Generators: 258 800 32%
H Function Generators: 68 400 17%
CLB Flip Flops: 84 800 10%
IOB Input Flip Flops: 0 160 0%
IOB Output Flip Flops: 0 160 0%
Memory Write Controls: 0 400 0%
3-State Buffers: 0 880 0%
3-State Half Longlines: 0 80 0%
Edge Decode Inputs: 0 240 0%
Edge Decode Half Longlines: 0 32 0%
Routing Summary
Number of unrouted connections: 0
================================= Xdelay Results ============================
Minimum Clock Period : 188.9ns
Estimated Maximum Clock Speed : 5.3Mhz
Xilinx LCA xdelay Ver. 5.1.0 ended normally
Article: 3081
In article <4iv52t$d4o@pcsi.pcsi.cirrus.com>, EPV <EPV@pcsi.cirrus.com> wrote:
>I have implemented delta sigma D/A which involves feeding back an adder's
output to
>its input and filtering the the MSB output to generate an analog value
proportional
>to the the input. How would one go about the inverse if that is even the
right way
>to put it? Block diagrams of sigma-delta A/Ds contain D/As and blocks called
>decimation filters. I am still confused as to what the analog values could
possibly
>mean to to a digital input pin I am guessing the signal are differentiated
and
>perhaps mixed with an oversampling frequency then you get some kind of freq
or pwm
>bit stream. I know, I am rambling. I am posting here because I want put this
in a
>Lattice 1016 which are very easy to use by the way.
>
Your mates at Crystal should be able to tell you much more than I know about
this, but here goes.
The A/D also needs some analog stuff, just like your D/A needs filter at its
output.
.-------------. .------------. .-------. Bit
| Analog | | | | flip | stream
Input----->|+ Integrator | ---->| Comparator |----->| D Q |--+---> To
.>|- | | | | flop | | Digital
| `-------------' `------------' `-------' | Filters
|.....................................................|
The reverse path <..... is can be though of as a 1 bit DAC, and the
comparator as a 1 bit ADC. The beauty of this is that having only two states
they are perfectly linear (simplification)
Article: 3082Hi, With all the schedual slips at major silicon vendors who are doing PCI implementations, I am wondering if the FPGA vendors are providing hard proved macro's which will be compadiable from the start? Anyone have experience with the major vendors PCI support? Good / Bad / zero? Thanks, Stan Hodge Grimes Aerospace stb@dnaco.netArticle: 3083
>The Altera EPX740/780 would meet your needs. They effectively go to 0 >current draw when they are idle. On board EPROM config bits, but SRAM >working logic. 10ns Tpd. The EPxxx parts did go to "sleep" if you >set the non-turbo mode bit, but the EP1810 was always a little >bizarre, and scooping up random logic was sometimes tough in the >segmented architecture. > For the EPX7xx parts you would need to use the Z suffix for low standby current. The EPX8xx chips have "zero" standby without any Z suffix and are in-system reprogrammable using flash memory, whereas the EPX7xx are one-time eprom. They also have a different programming voltage (12V for EPX8xx and 12.75V for EPX7xx). I am currently trying to decide whether to use EPX880 or Xilinx in an application where I originally used an Intel pld that they stopped making (N85C508-7). John WallikerArticle: 3084
Thomas, I'm not *real* familiar with the MINC tools or the Cadence tools, but this may be a clue... When the XACT 5 toolset came out, there were additions/changes to the .XNF file syntax. In some cases, there was no longer .XNF file compatibility between the two generations of tools. In other words, some older .XNF files were no longer readable by the latest tools (from Xilinx) without some "hacking". Could this be part of the problem you're seeing? Bob Elkind (formerly of Tektronix) Thomas Lane wrote: > I have stumbled across a problem with an archived Minc DSL design > targeting a Xilinx 3064PQ160. > > The design was originally completed with the 9403 version of Cadence's > Picdesigner. Now, using 9502 Picdesigner with the same DSL source, the > Xilinx part is dead. > > I have tried numerous experiments including makebits options, seeds, > aprloops, and guide files. Nothing worked. Out of frustration, I > have restored the 9403 version of Picdesigner in order to process the > design. This works... > > The last experiment tried was to process the design through the > PL-Partition step in 9502 and 9403, swap the XNF files, then continue > processing the design through the Cadence/Minc flow. The results: > > XNF file generated by 9502 Picdesigner (Partition) failed > > XNF file generated by 9403 Picdesigner (Partition) worked > > This could be a timing related issue: Xdelay outputs from both > routes are quite different. Interestingly, the Verilog timing > simulations from both working and non-working routes are the same.... > > Has anyone else had a similar experience? ************************************************************************** Bob Elkind email:videotek@rain.com CIS:72022,21 Video processing, R&D, ASIC, FPGA design consulting 7118 SW Lee Road part-time fax number: 503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903Article: 3085
We use the Bit Blaster on 8000 series parts and have found that they are very sensitive to the 1k pullup requirements on the DATA, CONF_DONE, DCLK and nSTATUS lines. We tried 10k and had many problems.Article: 3086
>I'm looking for an FPGA or EPLD to replace about a dozen CMOS >MSI and SSI parts. I expect to need about 40 I/Os. A very >important requirement is that the power consumption falls to >typical static CMOS levels (tens of microamps) when the clock >is stopped. I've noticed that the Altera Classic EP910 and >EP1810 seem to meet this requirement (in non-turbo mode), but >I'm wondering if there are others I should consider. >Availability of bare die and a few Schmitt inputs would be >significant bonuses, too. If you want bare die, then I'm assuming that you're building a multi-chip module. If so, do you have a way to program the dice? I have used Xilinx on MCMs with 5 volt only EEPROMs to hold the code. The EEPROMs were programmed on the module. -- +===============================================================+ + Joe Samson (313) 994-1200 x2878 + + Research Engineer, ERIM + + P.O. Box 134001 email samson@erim.org + + Ann Arbor, MI 48113-4001 + +===============================================================+Article: 3087
> >I'm looking for an FPGA or EPLD to replace about a dozen CMOS
> >MSI and SSI parts. I expect to need about 40 I/Os. A very
> >important requirement is that the power consumption falls to
> >typical static CMOS levels (tens of microamps) when the clock
> >is stopped. I've noticed that the Altera Classic EP910 and
> >EP1810 seem to meet this requirement (in non-turbo mode), but
> >I'm wondering if there are others I should consider.
>
> >Availability of bare die and a few Schmitt inputs would be
> >significant bonuses, too.
>
If you need just a few schmitt inputs and you can afford two pins
per input, you can fake it using positive feedback. The circuit
uses two i/os and two external resistors like this:
|\
Input ----/\/\/\-----------| >----------
| |/ |
| |
| /| |
-/\/\/\--< |-----
\|
The amount of hysteresis is easily adjusted by changing the ratio
of the resistor values.
-Ray Andraka
Chairman, the Andraka Consulting Group
401/884-7930 FAX 401/884-7950
mailto:randraka@ids.net
http://www.ids.net/~randraka/
The Andraka Consulting Group is a digital hardware design firm
specializing in high performance FPGA designs. Services include
complete design, development, simulation, and integration of these
devices and the surrounding circuits. We also evaluate,troubleshoot,
and improve existing designs. Please call or write for a free
brochure.
Article: 3088
-- Stan Hodge <stb@dnaco.net> wrote:
>Hi,
>
>With all the schedual slips at major silicon vendors who are doing PCI
>implementations, I am wondering if the FPGA vendors are providing hard
>proved macro's which will be compadiable from the start? Anyone have
>experience with the major vendors PCI support? Good / Bad / zero?
Xilinx has a few different PCI solutions available for FPGAs--some free
of charge, other sold and supported as products.
More information is available at
http://www.xilinx.com/apps/pci.htm
In summary, there are free reference designs available for our XC3164A
and XC7300FPGA and CPLD products. Xilinx also sells a fully-verified
PCI Target design, with integrated burst FIFOs for the XC4000E FPGA
family. The Initiator design is due out in June 1996.
=====================================================================
_
/ /\/ Steven K. Knapp E-mail: stevek@xilinx.com
\ \ Corporate Applications Mgr. Tel: 1-408-879-5172
/ / Xilinx, Inc. Fax: 1-408-879-4442
\_\/\ 2100 Logic Drive Web: http://www.xilinx.com
San Jose, CA 95124
=====================================================================
Article: 3089
In article <4ivccc$pr1@news1.cle.ab.com>, susnow@cle.ab.com (Dean Susnow) wrote:
> >I am currently using Synopsys / Xilinx and targeting
> >a 4005 part. I would like to perform post-route timing
> >simulation of the device. Unfortunately, we have not
> >purchased VSS (Synopsys Simulator). I would like to
> >know if anybody out there has used either Model-Technology
> >or Mentor's Quick-VHDL to do post route timing SIMs w/Xilinx.
> >I have gotten this to work from the Altera Tools, but
> >have not figgured it out for Xilinx
> >
> >Thanks:
> > Dean S. Susnow
> > susnow@cle.ab.com
If you have access to the Logic Modeling SmartModel library you
can accomplish the same thing. The .xnf file can be compiled
into a .ccn file using a tool in the library. This .ccn file which
our models read configures the particular device and gives you full
post-route timing.
This will work in MTI or QVHDL (on a unix workstation) The
technology is called SmartCircuit and with an option called PLDebug
can be quite useful during simulation as you won't loose visibility
into the netlist
Contact your Synopsys Logic Modeling Applications Engineer for
more details.
hope this helps.
-tim
--
tims@synopsys.com
Synopsys Logic Modeling Group
602.834.3837 (Ph) 602.834.4177 (Fax)
http://www.synopsys.com/products/lm/modelDir.html
Article: 3090ANNOUNCEMENT: Immediate Release VHDL Model of the Month ======================= This month's model is: An 8 bit ADC (Analog to Digital Converter) in VHDL You can find it at http://www.doulos.co.uk. You can also access previous Models and Tips of the Month from the same site. ____________________________________________________________________ Also *** NEW *** for this month are: TIP of the MONTH: Design for Debug VHDL Quick Reference Card VHDL 93 Update Reference Card _____________________________________________________________________ Also details of the latest Doulos VHDL and Verilog training courses and how to get a FREE online VHDL tutorial. 'TRAINING THAT GIVES YOU THE WINNING EDGE' Tim Pagden DOULOS Church Hatch Tel: +44 1425 471 223 22 Market Place Fax: +44 1425 471 573 Ringwood BH24 1AW Email: info@doulos.co.uk UK _____________________________________________________________________Article: 3091
ANNOUNCEMENT: Immediate Release VHDL Tip of the Month ======================= This month's Tip is: **************** Design for Debug **************** You can find it at http://www.doulos.co.uk. You can also access previous Models and Tips of the Month from the same site. ____________________________________________________________________ Also *** NEW *** for this month are: Model of the MONTH: 8 bit ADC VHDL Quick Reference Card VHDL 93 Update Reference Card _____________________________________________________________________ Also details of the latest Doulos VHDL and Verilog training courses and how to get a FREE online VHDL tutorial. 'TRAINING THAT GIVES YOU THE WINNING EDGE' Tim Pagden DOULOS Church Hatch Tel: +44 1425 471 223 22 Market Place Fax: +44 1425 471 573 Ringwood BH24 1AW Email: info@doulos.co.uk UK _____________________________________________________________________Article: 3092
So I've been thinking if V is too much of a step(leap) maybe we should start talking about how to cut these hardware objects into a C program. I wondering if VHDL and verilog and hardware C might be used as assembly. So how would one wrap a language like C or fortran around a hardware language VHDL or verilog. Many of you know how we do that here for C. Take the bit file and turn it into a static array #include that array into your C program and have a function that memory mappes a base register to a pointer. But I'm thinking that the thing we went through with the sqrt was good. If I had a library that contained all the hardware versions of the sqrt then in my complier I could say "look for VHDL in the library and through that to synopsys" Or "look for verilog and through the to cadence" But just for starters it might be nice to have a repository where we gather up functions and describe them in some set of languages. Anyway how about a good divide or e^x or log(x) algorithm? Have a good weekend:) Steve CasselmanArticle: 3093
husby@fnal.gov (Don Husby) wrote:
>> 3- "Porting anything is non-trivial"
>> [...]
>
>Yeah. Just try writing a "hello world" for Windows.
contrary to the public misperception, "hello world" for windows is also a five
line program. Try this:
#include <windows.h>
winmain()
{
MessageBox(0, 0, "hello world", MB_OK);
}
muzo
standard disclaimer
Article: 3094Eonic Systems, Inc. has joined today TechOnline, Inc. as a member company. Engineers will be able to browse through their products and pretty soon they will also be able to evaluate their software. URL http://www.techonline.comArticle: 3095
Hi, Having recently moved to XACT5.2 we are experiencing problems with the length count of the .rbt files causing the devices not to configure correctly. For a 3195APQ160 device using XACT5.0/5.1 the length count is 1730C. In XACT5.2 this count is now 17309 and does not work correctly. Have the defaults on makebits changed in 5.2 to produce different length files? Has anyone else experienced this? Regards, Jim Banks. -- *************** __ ************************************************** ************* / / ************ Jim Banks * *********** / / ********* HP Queensferry Telecom Operation * ********* / /___ ______ ******* email: jbanks@hpsqf.sqf.hp.com * ******** / __ // __ / ****** Mail: Station Road * ******** / / / // /_/ / ****** South Queensferry * ********* /_/ /_// ____/ ******* West Lothian, EH30 9TG * ********** / / ********* Scotland * ************ / / *********** Telnet: 313-2949 (+44-131-331-7949)* ************* /_/ ****************************************************Article: 3096
Steve Casselman (sc@einstein.vcc.com) wrote:
> Anyway how about a good divide or e^x or log(x) algorithm?
Here's one that does a Center-of-Mass calculation. It uses
two accumulators to generate the sum and weighted sum and then
implements a division using a log-subtract-exponent. The
division works on 9-bit numbers, but produces a 4-5 bit result.
I've implemented this circuit in ORCA with a cycle time of
20ns for the accumlators and 60ns for the division.
Accumulators 5 PFU Accumulate 10-bit WSUM and 9-bit SUM
Normalize 8 PFU Convert to 5-bit floating point + exponent
Divide 8 PFU Log tables, subtract, Exp table
De-normalize 2 PFU Shift by exponent
This is part of some data acquisistion electronics that tracks particles
through an array of pixels. The center-of-mass calculation adds about
3 bits of accuracy to the location of the particle.
Here's my simulation code to verify the algorithms (about 200 lines):
#include <stdio.h>
#include <math.h>
/* Simulation of hardware lookup table division.
Small lookup tables (~16-32 words by 4-6 bits) are used to implement
log and Exp functions. A division circuit implements A/B as
exp(log(A)-log(B)).
*/
#define NLa 32.0 /* Log table address width 2^n */
#define NLd 16.0 /* Log table data width */
#define NEa 16.0 /* Exp addr: Must be <= NLd */
#define NEd 32.0 /* Exp table data width */
#define Limit(A,B,Eps) fabs((A-B)/((A+B)/2)) > Eps
#define SFact 1.41 /* Scaling factor for log table */
#define Eps 0.06 /* Comparison limit */
int ExpFlag; /* Set if ExpTbl is < 1 */
/* Histogram stuff */
#define HSIZE 20
#define HBin 0.01
int Hist[HSIZE];
void Hist_init(void)
{ int I=HSIZE;
while (I>0) Hist[--I]=0;
}
void Hist_add(float A, float B)
{ int I= fabs(2.0*(A-B)/(A+B))/HBin +0.5;
if (I > HSIZE-1) I= HSIZE-1;
++Hist[I];
}
void Hist_disp(void)
{ int I,J;
int Max=0;
for (I=0; I< HSIZE; ++I) if (Hist[I] > Max) Max= Hist[I];
printf(" 0|");
for (I=1; I<=10; ++I) printf(" %5d|",(I*Max)/10);
printf("\n");
for (I=0; I< HSIZE; ++I)
{ printf("%8.4f",I*HBin);
if (Hist[I]==0) printf("."); else printf("*");
for (J=70.0*Hist[I]/Max+0.5; J--;) printf("*");
printf("\n");
} }
int Round(float F) /* Round float to nearest int */
{ int I;
I= (F<0) ? F-0.5 : F+0.5;
return(I);
}
/* Emulate log lookup table
The log table accepts a small integer which represents the address
bits of a lookup table. The integer represents the significant bits
of a value between 1.0 and 2.0.
For example, if the table has a 4-bit address, then the number 5
would represent 1+5/16 or 1.3125.
The output is the log of the input. It is scaled by ~1/ln(2) to
expand the output to full precision. For example, without scaling,
the 4-bit integer representing the log of the largest input (15) would
be 11= 16*ln(1+15/16). The scaling factor causes the number to be
15= 1.4*16*ln(1+15/16).
*/
int LogTbl(int I) /* I= short normalized float (1.0 <= I < 2) */
{ float F= 1.0+(I+0.5)/NLa; /* Convert to real float */
if (I>=NLa || I<0) printf("LogTbl value out of range %d\n",I);
F= log(F); /* Take log. (0 <= F < 1) */
I= Round(F*NLd*SFact);/* Expand and convert to short integer */
if (I>=NLd || I<0) printf("LogTbl result out of range %d\n",I);
return (I);
}
/* Emulate exponent table
This implements the inverse of LogTbl. It accepts small integers in
the range of +/-Nld which represent values from -1 to +1, converts
them to the table address width (+/-NEa), and then computes the
inverse log (with the same scaling factor as LogTbl).
The output is a short integer which represents a number from .5 to
2.0.
*/
int ExpTbl(int I) /* Emulate exp */
{ float F= Round(I*NEa/NLd);
ExpFlag= (I<0) ? -1 : 0;
F= F/(SFact*NEa); /* Convert to real float (-1 < F < 1) */
F= exp(F); /* (0.5 < F < 2.0) */
if (ExpFlag) F *=2.0;
I= Round(F*NEd); /* Cast to output width */
return(I);
}
/* Emulate divider
The divider accepts integers, converts them into short normalized
floating point numbers, and does a table-based division.
*/
int Divide(int A, int B) /* A and B are integers > 16 and A>B */
{ int I;
int Exp= 0 ; /* Exponent */
if (A<NLa) printf("Div: A out of range: %d\n",A);
if (B<NLa) printf("Div: B out of range: %d\n",B);
while (A >= 2*NLa) { A>>=1; ++Exp; } /* Normalize to 4-bit float */
A -= NLa;
while (B >= 2*NLa) { B>>=1; --Exp; } /* Normalize to 4-bit float */
B -= NLa;
I= ExpTbl(LogTbl(A)-LogTbl(B)); /* Do division */
Exp += ExpFlag;
if (Exp<0 || Exp > 2)
printf("Div: Exp (%d) out of range A=%d B=%d\n",Exp,A,B);
I <<= Exp; /* De-normalize */
return(I);
}
void C_O_M(int V[5]) /* Center-of-Mass calculator. Accept a */
{ int A=0,B=0; /* vector of 5 numbers and determine C.O.M. */
float F,G;
B += A; A += V[0]; /* Simulate Accumulators */
B += A; A += V[1]; /* At the end, */
B += A; A += V[2]; /* A= V0 + V1 + V2 + V3 + V4 */
B += A; A += V[3]; /* B= 4*V0 + 3*V1 + 2*V2 + V3 */
B += A; A += V[4];
G= Divide(B,A) / NEd;
F= (4.0*V[0] + 3.0*V[1] + 2.0*V[2] + V[3])
/ (V[0]+V[1]+V[2]+V[3]+V[4]);
Hist_add(F,G);
/* if (Limit(F,G,Eps)) /* Compare two results */
/* printf("Com %8.5f %8.5f %8.5f\n",F,G,(F-G)/((F+G)/2));
*/
}
/* Generate a hit vector.
Simulate a set of five 64x64 micron square pixels of dimension
(Z,Y)=64x320. Assume that the charge left by a track through a pixel
is equal to the track length, so a full scale (6-bit) reading is left
by a track traveling from one side to the other. (Diagonal tracks peg
the reading at full scale.)
The track through the pixels is described by the line Y=dY/64*Z+Yi
where Yi is the initial entry point at Z=0 (0<Yi<64).
and dY+Yi is the Y exit point at Z=64 (0<dY<512).
*/
void Hit(int V[5])
{ int Yi= random()&0x3f;
int dY= (random()&0x1ff)+1;
float Ychrg = sqrt(64*64+dY*dY)/dY; /* Charge per unit Y */
int Exit_pixel=(Yi+dY)/64;
int I;
if (Exit_pixel > 4)
{ for (I=0; I<=4; ++I) V[I]= 64*Ychrg; }
else
{ for (I=0; I<Exit_pixel; ++I) V[I]= 64*Ychrg;
V[Exit_pixel]= ((Yi+dY)%64)*Ychrg;
for (++I; I<=4; ++I) V[I]=0;
}
V[0] -= Yi*Ychrg;
for (I=0; I<=4; ++I) if (V[I]>63) V[I]=63;
/* printf("%3d %3d [%2d %2d %2d %2d %2d]\n",
Yi,dY,V[0],V[1],V[2],V[3],V[4]);
*/
}
main()
{ int I,J,R;
float F,G;
int V[5];
/* Print Tables */
/*
for (I= 0; I<NLa; ++I) printf("Log(%3d) = %3d\n", I, LogTbl(I) );
for (I= 0; I<NLd; ++I) printf("Exp(%3d) = %3d Exp(%4d) = %3d\n",
I, ExpTbl(I), -I, ExpTbl(-I));
*/
/* Test all cases of the tables*/
for (I=0; I<NLa; ++I) for (J=0; J<NLa; ++J)
{ F= 1.0+I/NLa; G=1.0+J/NLa;
F /= G;
G= ExpTbl(LogTbl(I)-LogTbl(J))/NEd;
if (ExpFlag) G/=2;
if (Limit(F,G,Eps)) /* Compare */
printf("Lt(%2d)=%2d Lt(%2d)=%2d Diff= %3d. %8.5f %8.5f %8.5f\n",
I,LogTbl(I),J,LogTbl(J),LogTbl(I)-LogTbl(J),F,G,F-G);
}
/* Test all cases of the division routine */
Hist_init();
for (I=NLa; I<256; ++I) for (J=NLa; J<I; ++J)
{ F=I; G=J; F/=G;
G= Divide(I,J) / NEd;
Hist_add(F,G);
/* if ( Limit(F,G,Eps)) /* Compare two rtesults */
/* printf("Div %4d %4d %8.5f %8.5f %8.5f\n",I,J,F,G,(F-G)/((F+G)/2));
*/
}
printf("Histogram of division errors.\n"); Hist_disp();
/* Test Random cases of C_O_M */
Hist_init();
for (I=1000000; --I;)
{ Hit(V); /* Generate a hit vector */
C_O_M(V); /* Compute COM */
}
printf("\nHistogram of COM errors.\n"); Hist_disp();
}
Article: 3097Jim Banks wrote: > > Hi, > > Having recently moved to XACT5.2 we are experiencing problems with > the length count of the .rbt files causing the devices not to > configure correctly. > > For a 3195APQ160 device using XACT5.0/5.1 the length count is 1730C. > In XACT5.2 this count is now 17309 and does not work correctly. > > Have the defaults on makebits changed in 5.2 to produce different > length files? > > Has anyone else experienced this? > Not as such, but we've padded out our bitstreams for a couple of years now, based on app.s info. from XILINX - just to make sure that the device gets enough bits. Extra bits get ignored by the device after it gets it's full quota, but too few bits causes problems (as you've found). -- Regards AndyG ------------------------------------------------------------------------ *** Terry Pratchett's 'Wyrd Sisters' on stage in Leeds - April 23-27 *** check out http://ourworld.compuserve.com/homepages/Whitkirk for details, or e-mail 73064.1273@compuserve.com ------------------------------------------------------------------------Article: 3098
ecp@focus-systems.on.ca (Eric Pearson) wrote: >In article <4id1dg$caj@bolivia.it.earthlink.net>, >David F. Spencer <starfire2@earthlink.net> wrote: >>Hi everyone. >> >>We're using the Actel Act2 family of FPGAs and I was wondering if anyone >>had any experiences with them (good or bad). The chip we're >>specifically using is the 1240A. It seems to be fairly capable but it >>has a lot of drive limitations, etc. Are these typical of other FPGA >>vendors? >> Yeah, I used the 133PGA 1240 part on a few projects and it was fine. No problems with fixing pins on later design revisions either (although I guess you can push anything _too_ far if you try hard enough). No problems with speed (used a 22Mhz clock on one project - fine) and I had no difficulties with drive capability (I was pushing quite a heavily capacitive databus too) Fine, although I did blow a couple without properly simulating first, and paid the price (well, actually, my company paid the price!!). Incidentally, I switched to Actel 1240s after using Altera 7256 parts (erasable), and I found them a great improvement in terms of speed/cost/usable gates, but then that was just one project & I might be biased. Enjoy, Rich Aplin.Article: 3099
Andy Gulliver wrote: > > Jim Banks wrote: > > > > Hi, > > > > Having recently moved to XACT5.2 we are experiencing problems with > > the length count of the .rbt files causing the devices not to > > configure correctly. > > > > For a 3195APQ160 device using XACT5.0/5.1 the length count is 1730C. > > In XACT5.2 this count is now 17309 and does not work correctly. > > > > Have the defaults on makebits changed in 5.2 to produce different > > length files? > > > > Has anyone else experienced this? > > > > Not as such, but we've padded out our bitstreams for a couple of years now, based on > app.s info. from XILINX - just to make sure that the device gets enough bits. > Extra bits get ignored by the device after it gets it's full quota, but too few > bits causes problems (as you've found). I ran into this as well. To the best of my poor recollection, it was indirectly caused by a change in the command line switches for MAKEBITS. The default (and syntax) for Done-Early/Late and Reset-Early/Late changed. The too-short bitfile bug (only in peripheral mode) was always there, but was exposed by the changed defaults. I was told by a support line guy years ago that MAKEBITS has no way of knowing which way I'm going to configure the part, so it can't correctly determine the bitstream length (peripheral mode must be padded up to the next byte length). Of course that argument makes no sense. I use command line switches to inform MAKEBITS of a bunch of other things. Why can't it take a command line switch that specifies how I'm going to configure the part and pad the bitstream accordingly??!! Live and learn, Scott
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