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
> Hi, > > FPGA 2003 is fast approaching. Now is the time to register and make your > hotel arrangements. I've attached the program, along with hotel and > registration details below. For more details, see the web site at > http://fpga2003.ece.ubc.ca > > > -------------------------------------------------------------------------= - > > Sunday, February 23, 2003 > ---------------------------- > > 6:00PM - Registration > 7:00PM - Welcoming Reception > > Monday, February 24, 2003 > ----------------------------- > > 7:30 AM - Continental Breakfast and Registration > 8:20 AM - Opening Remarks, Steve Trimberger, Russ Tessier > > Session 1. Novel Architectures > Chair: Michael Butts, Cadence > > 8:30 AM - Architectures and Algorithms for Synthesizable Embedded > Programmable Logic Cores, Noha Kafafi, Kimberly Bozman, and Steven J.E. > Wilton, University of British Columbia > > 8:50 AM - The Stratix Routing and Logic Architecture, David Lewis, Vaughn > Betz, David Jefferson, Andy Lee, Chris Lane, Paul Leventis, Sandy Marquardt, > Cameron McClintock, Bruce Pedersen, Giles Powell, Srinivas Reddy, Chris > Wysocki, Richard Cliff, and Jonathan Rose, Altera Corporation > > 9:10 AM - A Pipelined Configurable Gate Array for Embedded Processors, > Andrea Lodi, Mario Toma, Fabio Campi, Andrea Cappelli, Roberto Canegallo, > and Roberto Guerrieri, University of Bologna and STMicroelectronics > > 9:30 AM - Coffee Break and Poster Presentations > > > Session 2. Placement > Chair: Vaughn Betz, Altera Corporation > > 10:30 AM - Hardware-Assisted Simulated Annealing with Application for Fas= t > FPGA Placement, Michael G. Wrighton and Andr=E9 DeHon, California Institu= te of > Technology > > 10:50 AM - Parallel Placement for Field-Programmable Gate Arrays, Pak K. > Chan and Martine D.F. Schlag, University of California, Santa Cruz > > 11:10 AM - I/O Placement for FPGAs with Multiple I/O Standards, Wai-Kei Mak, > University of South Florida > > 11:30 AM - Poster Presentations > > 12:00 Noon: Lunch > > > Session 3. Routing > Chair: Jason Cong, UCLA > > 1:30 PM - Wire Type Assignment for FPGA Routing, Seokjin Lee, Hua Xiang, D. > F. Wong, Richard Y. Sun, University of Texas at Austin, UIUC, and Xilinx > Corporation > > 1:50 PM - PipeRoute: A Pipelining-Aware Router for FPGAs, Akshay Sharma, > Carl Ebeling, and Scott Hauck, University of Washington > > 2:10 PM - Stochastic, Spatial Routing for Hypergraphs, Trees, and Meshes, > Randy Huang, John Wawrzynek, and Andr=E9 DeHon, University of California, > Berkeley and California Institute of Technology > > 2:30 PM - Poster Presentations > > > Session 4. Prototyping, Verification, and Test > Chair: Majid Sarrafzadeh, UCLA > > 3:30 PM - Implementation of BEE: A Real-Time Large-scale Hardware Emulation > Engine, Chen Chang, Kimmo Kuusilinna, Brian Richards, and Robert W. > Brodersen, University of California, Berkeley and Tampere University of > Technology > > 3:50 PM - High-Level Modeling and FPGA Prototyping of Microprocessors, > Joydeep Ray and James C. Hoe, Carnegie Mellon University > > 4:10 PM - Reducing Pin and Area Overhead in Fault-Tolerant FPGA-based > Designs, Fernanda Gusm=E3o de Lima, Luigi Carro, and Ricardo Reis, > Universidade Federal do Rio Grande do Sul > > 4:30 PM - Poster Presentations > > 6:00 PM - Dinner > > 7:00 PM - 10:00 PM: Panel - Attack of the Killer Gate Arrays > > The ever-growing capacity and speed of FPGAs have brought them into the > heart of the silicon mainstream. Major ASIC vendors have responded by > reviving masterslice gate arrays, standard prefab die with design-specifi= c > metal layers. They claim lower NREs, quicker delivery and easier design > than cell-based ASICs, and lower unit cost, better speed, capacity and power > than FPGAs. > > Do these gate arrays spell doom for FPGA vendors' dreams of displacing th= e > ASIC as a mainstream silicon platform? Will the FPGA's high volume, > superior flexibility and time-to-market prevail? Or will they co-exist i= n > different classes of application? Why? When? > > We have assembled a panel of experts from FPGA and ASIC vendors and > academia to duke it out. Each panelist will give a short presentation > putting forward their point of view, then we'll have interactive debate > among the panelists and attendees. > > > Tuesday, February 25, 2003 > ----------------------------- > > 7:30 AM - Breakfast > > > Session 5. Logic Synthesis and Mapping > Chair: Steve Wilton, University of British Columbia > > 8:30 AM - Placement-driven Technology Mapping for LUT-based FPGAs, Jason > Cong, Ashok Jaganathan, and Joey Y. Lin, UCLA > > 8:50 AM - Verifying the Correctness of FPGA Logic Synthesis Algorithms, > Boris Ratchev, Mike Hutton, Gregg Baeckler, and Babette van Antwerpen, > Altera Corporation > > 9:10 AM - Using Logic Duplication to Improve Performance in FPGAs, Karl > Schabas and Stephen D. Brown, University of Toronto > > 9:30 AM - Coffee Break and Poster Presentations > > > Session 6. Device-Level Design > Chair: Guy Lemieux, University of British Columbia > > 10:30 AM - A Scalable 2V, 20 GHz FPGA using SiGe HBT BiCMOS Technology, J.R. > Guo, C. You, K. Zhou, M. Chu, B.S. Goda, R.P. Kraft, and J.F. McDonald, > Rensselaer Polytechnic Institute > > 10:50 AM - Design of FPGA Interconnect for Multilevel Metalization, Raphael > Rubin and Andr=E9 DeHon, California Institute of Technology > > 11:10 AM - Automatic Transistor and Physical Design of FPGA Tiles from an > Architectural Specification, Ketan Padalia, Ryan Fung, Mark Bourgeault, > Aaron Egier, and Jonathan Rose, University of Toronto > > 11:30 AM - Poster Presentations > > 12:00 Noon - Lunch > > > Session 7. Architecture Analysis and Evaluation > Chair: Sinan Kaptanoglu, Altera Corporation > > 1:30 PM - Architecture Evaluation for Power-Efficient FPGAs, Fei Li, Deming > Chen, Lei He, and Jason Cong, UCLA > > 1:50 PM - Post-Placement C-slow Retiming for the Xilinx Virtex FPGA, > Nicholas Weaver, Yury Markovskiy, Yatish Patel, and John Wawrzynek, > University of California, Berkeley > > 2:10 PM - An FPGA Architecture with Enhanced Datapath Functionality, > Katarzyna Leijten-Nowak and Jef L. van Meerbergen, Eindhoven University of > Technology and Philips Research Labs > > 2:30 PM - Coffee Break and Poster Presentations > > > Session 8. Innovative Applications > Chair: Ray Andraka, Andraka Consulting Group > > 3:30 PM - A Fully Pipelined Memoryless 17.8 Gbps AES-128 Encryptor, Kimmo U. > J=E4rvinen, Matti T. Tommiska and Jorma O. Skytt=E4, Helsinki University= of > Technology > > 3:50 PM - Methodology to Implement Block Ciphers in Reconfigurable Hardware > and its Application to Fast and Compact AES RIJNDAEL, Francois-Xavier > Standaert, Gael Rouvroy, Jean-Jacques Quisquater, and Jean-Didier Legat, > Universit=E9 Catholique de Louvain > > 4:10 PM - Energy-Efficient Signal Processing Using FPGAs, Seonil Choi, > Ronald Scrofano, Viktor K. Prasanna, and Ju-wook Jang, University of > Southern California > > > 4:30 PM - Closing Remarks, Steve Trimberger, Russ Tessier > > -------------------------------------------------------------------------= - -- > ----------- > > Hotel Information: > ------------------- > > FPGA 2003 will be held at the Monterey Beach Resort. Attendees who will b= e > staying at the hotel must make hotel reservations in addition to their > conference registration. To make reservations at the hotel, contact: > > Best Western Monterey Beach Resort > 2600 Sand Dunes Drive > Monterey, California 93940 USA > (831) 394-3321 > > Tell them that you are with the ACM/FPGA conference to get the conference > rate of $112 Gardenside or $162 Oceanside. The room rate is the same for > single or double. The conference cut-off date is February 1, 2003. > Reservations received after February 1 will be accepted on a space and rate > available basis only. > > -------------------------------------------------------------------------= - -- > --------------- > > Registration Information > ------------------------ > > Register on the web at http://fpga2003.ece.ubc.caArticle: 51676
edmurkin@yahoo.co.uk (Ed) wrote in message news:<d1d4588f.0301180402.235eef1e@posting.google.com>... > Matt <matt@NOSPAMpeakfive.com> wrote in message news:<3E2840CE.C588725C@NOSPAMpeakfive.com>... > > john jakson wrote: > > [a great description of working with ffts in hw, thanks] > > > > > If you try to > > > use HandelC to do real hw design at the level of detail hw guys would > > > get into, I'd say you beating a dead horse. > > > > I'll take your word for it, as that's kind of what I expected > > I'd disagree. The difference in approach I believe with a language > such as Handel-C or VHDL, is that with VHDL you describe the hardware > you want to build, with Handel-C you describe the problem you want to > solve, ie. the algorithm. > > We have evaluated Handel-C and the results are impressive. It's not a > replacement for VHDL but for our work with Virtex II Pro and Excalibur > has shown the value of Handel-C. It can partition designs with a > technology called DSM and the EDIF output produces good QoR. We also > output Verilog and VHDL from the Handel-C compiler and ran this > through Synplify with a direct link from Handel-C to Synplify. > > There are simple optimization techniques > > Verilog/VHDL lets you describe the HW you want to build, at higher levels of the hierarchy, the netlist of instances or schematic could look alot like the algorithm so you could say the language allows to describe algorithms pretty well for such simple things as FIR/IIR filters that are mapped directly. Its when you get clever and start cycling common resources like a multipliers over the operators in the algorithm creating datapaths & sequencers & microcode, that it is more implementation/design time than clear algorithm. In other words, right now Vxxx forces you to make most of the detailed design decisions & do most of the micro architecture work. HandelC lets the tools do the lower level architecture, as I said before its a Behavoural Compiler & has its place, and I have been impressed with some showroom demos. I am more partial to hC due to Occam connection, but what really galls me about it is that it is a proprietary language & you can't go out and buy books on it & this will ultimately cripple it as well as the price. For those FPGA EEs that aren't familiar with ASIC/VLSI design, Behavoural Compiler BC from Synopsys have been around a few years (10?) and has been largely scorned by ASIC guys as not being able to produce anywhere as near good results. The big advantage of Synopsys BC is that it eats Verilog (maybe VHDL) and works with DC (regular synthesis). If BC were for C, it would have been even more scorned, C has alot of enemies in ASIC land. For ASICs this lack of equivalent performance is critical, ASICs must be produced in the quickest time at highest speed & lowest cost before the competition kills you. Even if the design can be done quicker by BC than by expert, the ASIC project is plagued by much longer backend flow and the months of Fab time. A bigger chip compounds the backend problems. For some FPGA projects, it is acceptable to have less performance to get something done more quickly. Taken to its logical conclusion this is RC, every PC could have FPGA fabric in the CPU (Intel please) and the Visual C++ tools could include BC to FPGA, but this will be along time coming. It has occured to me that a Virtex Pro could be the basis for a ppc Mac clone, & with MOL could run OSX under YellowDog....but I digress. My own preference though would be to have BC work with Verilog rather than hC as I could choose what parts go automagic & what doesn't. The Verilog can also go through V2C to give a fast C model for simulation and can be mixed in with a C app or C testbench. As an aside, one of the biggest talking points at DAC and in the ASIC business is the cyclical reinvasion of C and the SW guys that thinks C should replace Vxxx. Almost all have gone out of business (except Celoxica) and their assets in boxes at Synopsys. There is SystemC language that Synopsys is pushing so that if C does take off, it remains in control. But even SystemC is not intended for BC but for system modelling. What really nerves the ASIC guys (me included) is that the Verilog tools already work well and the language describes HW well. Almost everybody has at one time or another also used Cxx to do HW design, but its always a question of reinventing all the tools for a language that is really poor at detail HW description. end of rantArticle: 51677
>Yes. It works. What the problem? Just put the databits (byte) to Din, raise >the CCLK, do this for all config-bytes. Add another dummy byte for the >startup-sequence. Finished. Yes, I2C MIGHT not work (havnt tried it, also >Iam not so familiar with I2C), since the protocoll is different to SPI, but >SPI DOES work. Its just a simple 8 bit paralle/serial converter. My guess is that I2C and SPI have another layer of protocol that isn't useful for configuring a FPGA. If you use the low level wires they probably work OK. They are often implemented by bit-banging which would make things easy. I think that sort of system normally uses an open-drain type driver with a pullup. It might be worth checking for noise on the slowly rising clock line. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 51678
Steve Lass <lass@xilinx.com> wrote in message news:<3E28724C.20AD283A@xilinx.com>... > Langmann wrote: > > > Are you sure? I may be wrong about this (my PC with the Webpack installation > > is not available to me right now) but I think I remember seeing directories > > of Virtex (and possibly some other non-supported families) configuration > > data included in the installation. > > We include these directories for a variety of reasons, like: > - VirtexE has a lot of common elements with Virtex, so the VirtexE tools get data from the Virtex directories. > - The programming daisy chain may contain other devices, so we include programming info for all devices. > Is it possible then to use newer WebPack to program chips supported by older versions by just copying data from old installation to new directories? Computers get quite confused with multiple versions of WebPack installed.Article: 51679
John,
I was referring to cloning the CPU in the FPGA. Doing that doesn't make sense. Replacing a cpu
with a customized data path processor does make sense in many applications. I have seen people
use FPGAs as crossbar switches (have even done it myself) to connect CPUs in a programmable mesh.
It really depends on what your application is.
Recently used floating point in radar, averaging many echoes; large FFT's; spectrum analyzer. It
is also useful in division to reduce the size of the hardware. Mind you, not every operation is
done in floating point, nor is it typically ieee floats, rather we size both the exponent and the
significand to fit the expected dynamic range and required precision. Usually, we'll normalize,
strip off the exponent and then do a fairly lengthy set of fixed point operations on the
significand, possibly incrementing the exponent in strategic places, then at the end of the
process renormalize and marry the passed around exponent back with the processed data.
john jakson wrote:
> Actually replacing the cpus is precisely what FPGAs are good for when
> 10% of code keep cpus busy 90%. It would seem a strange thing to let
> cpus compute & route through FPGA hw.
>
> So now you are doing FP, whats the application?
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 51680
john jakson wrote:
>
> Ray wrote
> Regarding the FFT, Cooley Tukey is more or less a software algorithm.
> There
> are other factorizations that significantly reduce the number of
> multiplies. For example, a radix 16 Winograd FFT only requires 14
Oops, that should have been 18, however several are by +/-1. IIRC, there are 6 unique factors if
you exclude sign and include unity. Winograd does not generally make sense in a software
implementation because the reordering is irregular making the loop and addressing structure
awkward. In hardware, where multipliers are generally expensive compared to adds it becomes
considerably more attractive. Quantization in the winograd also results in a slightly higher
noise floor when compared to C-T with the same word sizes.
>
>
> Winograd was on tip of my tongue hence the Blahut ref. But not many
> folks venture into these books & turn to it to HW since muls on a cpu
> get replaced by adds & moves might still not win out. Was great when
> muls were many cycles though.
>
> Acording to Blahut, he gives 10(18) muls & 76 adds. Would this op be
> exactly equiv to say a general rad16 composed of say 8 rad4s or 32
> rad2s with slight diff errors, and can this block be used in any rad16
> stage but with diff coeffs?
With infinite precision the result from a 16 point winograd FFT is exactly the same as from a
radix 16 C-T kernel (which is built up from smaller ones usually). You can use either one the
kernel for doing larger FFTs by putting a phase rotation and data reorder between each pass
through the 16 point kernel. C-T has the equivalent of a complex multiply cascaded with the
radix-2 butterfly, so what is normally done is that the rotation is factored into each pass as
twiddle factors. For larger FFT's you wind up needing a fairly large table of twiddles. The
Winograd refactors the complex multiplies, so the twiddles are not really the same thing. We
cascade ours by adding a phase rotator between the passes through the 16 point kernel.
Essentially, you wind up with an additional complex multiply between each 16 point kernel, but
with a 16 point kernel this is still less complicated than the C-T 16 point kernel, especially
since the multipliers inside the winograd can be limited set multipliers (jus t a few fixed
coefficients, no twiddle table).
>
>
> I think the big reason the exotics don't get used is that Matlab users
> and most FFT libs use rad2 ct. If I had to use really fast SW FFT, I'd
> probably just use Intels MMX/SSE tuned asm code.
C-T is the most often referenced FFT algorithm. Many folks are not even aware that there are
other FFT algorithms available. I've seen statements such as an FFT's length must be a power of
two. While that is true of the C-T algorithm, it is not true for all. Blahut's book goes into
considerable detail on other algorithms. Smith an Smith's FFT book is, I think gives a more
readable coverage of perhaps a larger set of algorithms, but it is also written with a very strong
software slant. I finally did get my own copy of Blahut, after waiting for nearly two years for
alibris, amazon et al to turn up a used copy (it is out of print). Smith and Smith (IEEE press)
is available through the bookstore on my website.
>
>
> JJ
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 51681Roger Green <rgreen@bfsystems.com> wrote: > I was actually referring to the post-route timing analysis in both > cases. Since the > source design is the same and the Xilinx PAR settings are identical, I'm > led to > believe that the difference is primarily due to the synthesis tool > used. Although Which versions of the tools are you using? Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 51682
Later in this thread someone suggests contacting Synplicity support to see if they can take a look at the setup and make suggestions. I have to second that. Without being able to see the design I can give you a few things to look for. This may be useful to others. Some background first: One difference between between Synplify and other FPGA synthesis tools is that it is heavily timing constraint driven. Most ASIC synthesis tools behave this way also. The other strategy in use is to compile for area or delay. Optimizing for delay would try to minimize levels without much regard for resource use. Synplify will try, in its estimation, to meet your timing goals with the smallest area. For large designs this will usually give the best real performance because it keeps the wires short and also keeps you in a smaller (and cheaper) part. The complication is that Synplify is only estimating the routing delays and can in some designs/paths be overly optimistic or pessimistic about routing. It may therefor sometimes leave a timing optimization undone because it thinks it already met the goal and is conserving area. 1) Check that the number of paths covered by constraints is similar. We often see a large difference in the number of covered paths based on constraints forwarded by the synthesis tools. It may be that the paths you are seeing in the Synplify result are just not covered in the XST result. 2) Synplify by default constrains I/O delays to 1 period of the controlling clock. I don't think XST does. You can set default input and output constraints of -100ns to match the XST constraints. This is one common cause of (1) above. 3) Synplify may be underestimating routing delays. You can compensate for this in Synplify's constraints. There is an adjustment option in the clock, I/O, and register constraints that can be used to tighten or loosen synthesis constraints without changing the constraints written to the NCF. In the various pages of the constraint editor (SCOPE) you will find columns labeled "route". Put your adjustment there. A positive number of ns will tighten the constraint and a negative number will loosen the constraint. Do not use extreme values especially for I/O or register adjustments because it can be like squeezing a balloon. Try to keep the values under 10% of your clock period. The first place to try an adjustment is in the clock constraint. 4) Constraint driven synthesis can backfire if you have a core with significant setup or clock to out delay with no timing model. Synplify's default assumption is 0ns setup and 0ns clock to out. We should probably have used at least the flip-flop setup and clock to q, but we didn't. We are working on the whole issue of modeling cores. For now, if your critical paths enter or exit a core, then the best thing to do is to supply a model. Hopefully one of these will clear up your problem. If not, then I would repeat the first suggestion of contacting Synplicity support. - Ken McElvain, CTO Synplicity Roger Green wrote: > I have recently been driven to switch to Synplify synthesis, from XST, for a > fairly complex PCI core VHDL design targeting a Virtex 300 in order to work > around various ISE tool bugs (which is another story all together). After a > fairly painful conversion of constraints (for both timespecs and previous > floorplannning) and getting the design to actually compile again, I have > noted that the logic paths now failing to meet my timespecs are in logic > that previously was not a problem with XST synthesis, although there were > problems paths then also. At first glance, my "gut" says that there are > more logic levels (LUTs) being used in the problematic paths, but I don't > have a direct proof of that, since I never actually looked at these specific > paths with the XST runs. I am using the identical "max" effort settings for > PAR settings as before the synthesis tool switch. > > I was wondering if any of the experts here have had any similar or different > experiences regarding the "performance" of these two tools on the same > source design. Or perhaps someone could point me to some links to any > "objective" comparison of these tools and/or information regarding what > types of logic each is better/worse at optimizing? > > -- > Roger Green > B F Systems - Electronic Design Consultants > www.bfsystems.com > > >Article: 51683
Ad Verschueren <ad.verschueren@NOxs4all.SPAMnl> wrote in message
--- SNIP ---
> I cannot resist (as designer of the IDaSS tool) to counter your remarks ;-)
> Just to indicate that (IMNSHO) good schematic tools which stop at the right
> point with using schematics are a good alternative to HDL's. Feel free to
> comment, of course - I can take criticism :-)
>
> I put a link to the IDaSS homepage at the end ;-)
>
Had a peek - looks interesting. I was talking about "dumb" schematics
- put components on a page and connect them. This appears to be much
smarter S/W.
>
> > * Schematics can make the design structure and data flow more
> > visible? sure, if your design flows data from one end to another.
>
>
> Yep - good practice in drawing schematics.
Well, usually can be done in DSP-type and similar designs; I work
mostly at Datacomm, where it's harder; for example, a DMA-controller
(pretty common element in Datacomm designs) will not have data flow
from one end to the other: everything flows from the BIU back to the
BIU.
-- SNIP --
> In IDaSS, clock and reset are implied, no need to draw them. Also,
> control and test signals from/to FSM's are not drawn but connected
> by name from within the FSM description. You only see data buses and
> RTL level blocks (which include the FSM's and sub-schematics) on the
> schematics.
Can you connect a signal from one low-level block to another low-level
block without routing it through a higher-level connecting block? does
it mean that all signals are global? if not, how do you separate
global from stricly-local signals? and how do instantiate more than
one instance of the same block?
>
>
-- SNIP --
>
>
> In IDaSS, you use a comment window to attach comments to blocks,
> individual connectors, data buses, complete schematics etc. Comments
> are also placed in all textual descriptions (FSM states, combinatorial
> logic functions, data-to-control signal decoders etc.).
You still have to cause the S/W to pop-up the comments, which are
usually hidden; it makes browsing the design harder (at least for my
style of browsing).
>
>
-- SNIP ---
>
>
> In IDaSS, yes. If you tell a register block to increment or decrement,
> it is a counter. This can be done continuously, under control of an
> FSM (or more FSM's, as long as they don't send conflicting commands) or
> controlled by decoding values on a databus.
What about "odd" counters? you have to write an FSM - which makes it
an HDL design!
>
>
> > * Maintaining a design: say you need an up/down counter which counts
> > between 5 and 27. In your schematics it wil be a mess of gates and
> > FFs;
>
>
> As I indicated, a counter or an FSM or an ALU can be one block in IDaSS,
> a few words of comments like 'counts between 5 and 27' suffice here.
>
> > after you haven't touched this part of the design for a few
> > months, you'll have to scratch your head quite a lot to understand
> > what it's supposed to do (been there, done that). In an HDL design,
> > even if it's uncommented, you can understand what it does in a glance.
>
>
> With that last statement, I have to disagree completely - I'm not allowed
> to show you a piece of Verilog which even the original designer does not
> understand anymore (so they asked me to do a review - I've started drawing
> schematics). Undocumented HDL is a capital offence.
>
Sure, any bad designer can create an unreadable design using any set
of tools. (or even a good designer who wants his design to be
unreadable as Job Security). What I an saying is that it IS easier to
make HDL code understandable than making schematic design, because you
are working at a higher level of abstraction: you don't have to
examine a mess of gates and FFs to understand what this counter/FSM is
supposed to do.
>
> > * Navigating the design: most schematic tools have very poor search
> > capabilities, compared to text editors. It's much easier to follow
> > signals, especially as the display is much denser: I can view
> > something like 100 lines of text at once, which can represent, for
> > example, a state machine which will require many schematic pages.
>
>
> If the HDL writers took care to keep signal names consistent, following
> them can be done. It is not easy, though, when working on a multi-million
> gate VLSI (described with several hundred HDL files).
>
> For IDaSS, I've chosen very early on *not* to represent FSM's graphically.
> Instead, I use a specially tailored language which directly names the
> blocks to test and control and uses readable names for the commands to
> send to the blocks. State transitions are also easily spotted and the
> states themselves are named.
>
>
> > * Version Control: you can save schematics in a VCS; but how do you
> > compare versions? once, long ago, I've thought of writing an
> > application to read graphic representation of a schematic (using
> > HP-GL, then used for most printing), and then overalying the output
> > graphics on a display. After some thought, I gave it up and returned
> > to the old method of overlaying the schematics on a light table - very
> > hard work.
> >
> > In a text-based design, you can very easily compare version: aha! I've
> > added a pipeline register here! so THAT is the bug! all in a few
> > minutes.
>
>
> I have to agree - IDaSS is lacking version control. Is on the to-do list...
> In our design team at work (where we use 'raw' Verilog, not IDaSS :-( ),
> we *have* to use a version management tool - we would be absolutely lost
> without it.
>
>
> > * Simulation & verification: if your design is a schematic, how do you
> > simulate?
>
>
> Hah - that is probably IDaSS's strongest point: the simulator is integrated
> with the 'design entry' tool. The 'SUD' ('System Under Design') is being
> simulated while it is built. The schematics are alive, and you have access
> to the state (and not only for inspection, also for changing it) at all
> times. You can clock step the simulation, change values in registers and see
> results of combinatorial logic immediately change, run for a specific
> simulation time or number of clocks...
What about simulating the whole system? often, simulating a single
block is not worth it, since it requires too much interaction with the
rest of the system.
>
> > usually you draw waveforms (or the text equivalent of
> > writing test-vectors) - more of the same hard work. When your design
> > is HDL, you can create an interactive test-bench (with the design,
> > sadly not with you)
>
>
> The 'I' in IDaSS stands for Interactive - and the interaction is indeed
> with the user (although you can easily create 'old fashioned' test
> benches if you want, there is even a special block which allows you
> to write test programs for execution in connection with the RTL design -
> more than one of these blocks can be used, they allow interrupts to be
> modelled, etc. etc.).
>
> > and automate the whole process; run it at night
> > and in the morning you see, before your first coffee, if it worked or
> > not.
>
>
> Yup - and then you may have to dig into millions of clock cycles of data
> to find where it went wrong - ooops, did not log that signal :-(
> I know that drill and I have to live with it... Regression testing
> has its merits and must be done - should be first time right, though.
Well, that's part of the job... hopefully, when you've reached the
point of simulating the whole system, you have already simulated each
sub-system in a stand-alone environment; if you find a bug, you can
often create the behavior in the smaller sub-system test-bench and
test your fix in a stand-alone environment before running regression
testing. Anyway, testing is a pain - I'd much rather be writing code!
;) have to do it, though.
>
>
> > All that said, I still belive that a person who has schematic design
> > experience will usually create better HDL designs, the same way that a
> > programmer who has Assembly code experience will usually write better
> > high-level language code.
>
>
> I absolutely, completely agree - I taught at University, and made sure
> the students could write assembly as well as 'high level' C (oh, and
> they designed working microprocessors with IDaSS in their first year).
>
> OK, the promised link to the 'Interactive Design and Simulation System'
> (IDaSS) homepage:
>
> http://www.xs4all.nl/~averschu/idass
>
> Greetings and have fun,
>
> Ad Verschueren
To summarize: it appears that your IDaSS is a mixed HDL/schematic
tool; many of the smarts in it are exactly because it uses HDL for
some of its functionality. I an NOT putting it down: each designer and
each design will prefer a different style of design, and there are
tools which have a similar set of capabilities, starting from HDL code
instead of schematics (there is a tool which was once called Renoire
(I think that's the was it is spelled; it was since named something
else); I've looked into it, run an evaluation license and decided it
was not for me - doesn't fit my style).
I guess we can agree that "best" method is a mix of both HDL and
schematic, and each designer should mix to taste (add salt and
pepper).
Article: 51684"Hal Murray" <hmurray@suespammers.org> schrieb im Newsbeitrag news:v2jgj32jt71e5@corp.supernews.com... > My guess is that I2C and SPI have another layer of protocol that isn't > useful for configuring a FPGA. > > If you use the low level wires they probably work OK. They are often > implemented by bit-banging which would make things easy. That the way SPI works. There is NO higher layer definition, it is specific for every SPI component. Some use 8/16/32/whatever bits per access, buts AFAIK its always a multiple of 8. Also the clock polarity is adjustable on most controllers. > I think that sort of system normally uses an open-drain type driver > with a pullup. It might be worth checking for noise on the slowly > rising clock line. No, SPI uses a normal push-pull output for the clock line, only I2C has open drain drivers (to allow slow slaves to slow down the transfer). -- MfG FalkArticle: 51685
Assaf Sarfati wrote:
> Ad Verschueren <ad.verschueren@NOxs4all.SPAMnl> wrote in message
>
> --- SNIP ---
>
>>I cannot resist (as designer of the IDaSS tool) to counter your remarks ;-)
>>Just to indicate that (IMNSHO) good schematic tools which stop at the right
>>point with using schematics are a good alternative to HDL's. Feel free to
>>comment, of course - I can take criticism :-)
>>
>>I put a link to the IDaSS homepage at the end ;-)
>
> Had a peek - looks interesting. I was talking about "dumb" schematics
> - put components on a page and connect them. This appears to be much
> smarter S/W.
Thanks for the compliment ;-)
>>>* Schematics can make the design structure and data flow more
>>>visible? sure, if your design flows data from one end to another.
>>
>>Yep - good practice in drawing schematics.
>
> Well, usually can be done in DSP-type and similar designs; I work
> mostly at Datacomm, where it's harder; for example, a DMA-controller
> (pretty common element in Datacomm designs) will not have data flow
> from one end to the other: everything flows from the BIU back to the
> BIU.
I agree - but folded paths like those can easily be drawn clearly.
If it gets hard to draw a clear schematic with clear data flow directions,
you will probably have to take the abstraction level up (with more
sub-schematics) or scratch your head and think about why this is never
gonna work...
> -- SNIP --
>
>>In IDaSS, clock and reset are implied, no need to draw them. Also,
>>control and test signals from/to FSM's are not drawn but connected
>>by name from within the FSM description. You only see data buses and
>>RTL level blocks (which include the FSM's and sub-schematics) on the
>>schematics.
>>
> Can you connect a signal from one low-level block to another low-level
> block without routing it through a higher-level connecting block?
Data buses have to be routed via higher level schematics, just like in
normal HDL's where you have to connect the instances of modules with
simulated wires.
FSM's can control (and test) blocks in their own schematic and any
sub-schematic within and below that schematic - they are restricted
to follow the hierarchy of the system downwards.
> does
> it mean that all signals are global?
No - definitely not. Communication is just as local as any other HDL,
with one exception which most HDL's do not even provide: The global
'signals' in IDaSS are system-wide single bit semaphores (actually, FF's)
which can be controlled and tested by all FSM's in a system. The're
specifically meant for system wide synchronisation and status distribution.
And again, you don't need to draw any lines to use these - their creation
and state monitoring/changing is done centrally from the system top level.
> if not, how do you separate
> global from stricly-local signals?
I think I answered that above - if you want more details, just ask...
> and how do instantiate more than
> one instance of the same block?
That is done at the level of complete schematics. A schematic 'contents'
can be placed under multiple schematic 'symbol' blocks all over a design.
Each of these instantiations gets its own state, but the specification is
a common one. If you add a register to one of those re-used schematics,
it will pop up in all other one's too (visibly - if you have editor
windows opened on them), changing the current value of that new register
is a local operation in that instance only (which can be demonstrated by
attaching a 'value viewer' to the register, which itself will also pop up
in the other windows).
> -- SNIP --
>>
>>In IDaSS, you use a comment window to attach comments to blocks,
>>individual connectors, data buses, complete schematics etc. Comments
>>are also placed in all textual descriptions (FSM states, combinatorial
>>logic functions, data-to-control signal decoders etc.).
>
> You still have to cause the S/W to pop-up the comments, which are
> usually hidden; it makes browsing the design harder (at least for my
> style of browsing).
Agreed, but popping up the comments is made as simple as possible: the
comment window is operated with single mouse clicks on the element you
want to inspect (that single mouse click also gives information regarding
the clicked element in the 'message' sub-window). You don't have to scroll
a text file to find the comments attached to a design element - just point
and click. Oh - and IDaSS can generate a full textual report on the design
(which includes the comments) automatically.
> -- SNIP ---
>
>>In IDaSS, yes. If you tell a register block to increment or decrement,
>>it is a counter. This can be done continuously, under control of an
>>FSM (or more FSM's, as long as they don't send conflicting commands) or
>>controlled by decoding values on a databus.
>
> What about "odd" counters? you have to write an FSM - which makes it
> an HDL design!
Depends on how "odd" they are. Generally, a register which is cross-
connected with input and output to a combinatorial 'operator' block
allows you to do just anything. If all you need is a counter with
weird end and restart values, you can always do the following:
- Connect the output of the register back to a 'control input'
connector on the register. This connector can generate local
commands for the register, based upon the value present on the input.
- Specify what you want to do with the register in two parts:
1) it should normally increment (that's the 'default command')
2) if (f.i.) the value is 27, it should reset to 5 - this is done in
the control input with the 'HDL' statements
27 setTo: 5 "If value is 27, it becomes 5 on the next clock"
- Don't forget to specify a value to be loaded into the register on
system reset (the 'system reset value').
>>>* Maintaining a design: say you need an up/down counter which counts
>>>between 5 and 27. In your schematics it wil be a mess of gates and
>>>FFs;
If you really need a counter which counts from 5 to 27 and back, you do
indeed need an FSM (and a register). In IDaSS, that is *all* you need -
it would be stupid to go down to the level of gates and FF's. The 'do-
it-yourself' demo in the 'short form' IDaSS manual gives a good example of
how this is done - makes it even more complex by not using a counter but
a shift register which shifts a 1 bit from right to left and back.
>>>after you haven't touched this part of the design for a few
>>>months, you'll have to scratch your head quite a lot to understand
>>>what it's supposed to do (been there, done that). In an HDL design,
>>>even if it's uncommented, you can understand what it does in a glance.
>>
>>With that last statement, I have to disagree completely - I'm not allowed
>>to show you a piece of Verilog which even the original designer does not
>>understand anymore (so they asked me to do a review - I've started drawing
>>schematics). Undocumented HDL is a capital offence.
>
> Sure, any bad designer can create an unreadable design using any set
> of tools. (or even a good designer who wants his design to be
> unreadable as Job Security).
Oh, absolutely :-(
> What I an saying is that it IS easier to
> make HDL code understandable than making schematic design, because you
> are working at a higher level of abstraction: you don't have to
> examine a mess of gates and FFs to understand what this counter/FSM is
> supposed to do.
It should be clear by now that IDaSS stays away from gates and FF's -
it works at RTL. One of the examples delivered with IDaSS is an 8048
processor core (minus I/O and interrupt related logic) - takes 14 IDaSS
RTL blocks on a single (and readable) schematic. IDaSS simulates this
processor running a short program with 10.000 simulated clock cycles in
less than 6 seconds (just timed it...). That simulation takes abstract
gate level timing into account (done to help find critical paths *very*
early).
...snip!...
>>>* Simulation & verification: if your design is a schematic, how do you
>>>simulate?
>>
>>Hah - that is probably IDaSS's strongest point: the simulator is integrated
>>with the 'design entry' tool. The 'SUD' ('System Under Design') is being
>>simulated while it is built. The schematics are alive, and you have access
>>to the state (and not only for inspection, also for changing it) at all
>>times. You can clock step the simulation, change values in registers and see
>>results of combinatorial logic immediately change, run for a specific
>>simulation time or number of clocks...
>
> What about simulating the whole system? often, simulating a single
> block is not worth it, since it requires too much interaction with the
> rest of the system.
The whole 'SUD' is in the Object-Oriented design/simulation database within
IDaSS. If you are working on one sub-schematic deep in the hierarchy, the
remainder of the system is there to surrond it and will be simulated with it.
This does not slow down design entry because you're not simulating clock
cycles then - you may be breaking or creating asynchronous paths and
these changes are simulated on the fly (which takes no noticeable time).
Other simulations while working on a sub-schematic are normally done a (few)
clock(s) at a time, IDaSS is more than fast enough not to make you sit and
wait while that happens.
>>>usually you draw waveforms (or the text equivalent of
>>>writing test-vectors) - more of the same hard work. When your design
>>>is HDL, you can create an interactive test-bench (with the design,
>>>sadly not with you)
>>
>>The 'I' in IDaSS stands for Interactive - and the interaction is indeed
>>with the user (although you can easily create 'old fashioned' test
>>benches if you want, there is even a special block which allows you
>>to write test programs for execution in connection with the RTL design -
>>more than one of these blocks can be used, they allow interrupts to be
>>modelled, etc. etc.).
>>
>>>and automate the whole process; run it at night
>>>and in the morning you see, before your first coffee, if it worked or
>>>not.
>>
>>Yup - and then you may have to dig into millions of clock cycles of data
>>to find where it went wrong - ooops, did not log that signal :-(
>>I know that drill and I have to live with it... Regression testing
>>has its merits and must be done - should be first time right, though.
>
> Well, that's part of the job... hopefully, when you've reached the
> point of simulating the whole system, you have already simulated each
> sub-system in a stand-alone environment; if you find a bug, you can
> often create the behavior in the smaller sub-system test-bench and
> test your fix in a stand-alone environment before running regression
> testing. Anyway, testing is a pain - I'd much rather be writing code!
> ;) have to do it, though.
I know - I'm currently keeping track of the tests performed on a multi-Mgate
ASIC - I hardly come around to run actual tests, let alone do some design
work. Tough job, but somebody has to do it very thoroughly. Sigh...
One of the main points we found over the years working with IDaSS is that
it allows much higher quality of code to be generated the first time
around. Most of this is due to the fact that it is very easy to test all
'corner cases' of a design's functionality. You don't have to come up with
difficult test sequences to reach the state needed for testing a corner
case - you can directly set up the state you want and run the test from
there. This way of working can be taken a step further: it is possible to
test immediately if your combinatorial logic is taking all the right
'decisions' based upon the state values fed into it - you don't even need
to simulate clock cycles to do that kind of testing as you have access to
all values generated by the combinatorial logic. Seasoned IDaSS users
perform these tests while they are building a design - they do not wait
until it's 'finished'...
...Snip!...
> To summarize: it appears that your IDaSS is a mixed HDL/schematic
> tool; many of the smarts in it are exactly because it uses HDL for
> some of its functionality.
Correct, one remark: IDaSS uses different sub-HDL's for different types
of functionality - where applicable using common constructs.
> I an NOT putting it down: each designer and
> each design will prefer a different style of design, and there are
> tools which have a similar set of capabilities, starting from HDL code
> instead of schematics (there is a tool which was once called Renoire
> (I think that's the was it is spelled; it was since named something
> else); I've looked into it, run an evaluation license and decided it
> was not for me - doesn't fit my style).
Yep - tool was called 'Renoir' (after the painter) IIRC. At work, we also
use a graphical 'front end' called 'Ease'. Ease is linked to a 'normal'
HDL simulator (and Renoir is too, AFAIK) - they do not provide the
interactive simulation of IDaSS.
> I guess we can agree that "best" method is a mix of both HDL and
> schematic, and each designer should mix to taste (add salt and
> pepper).
I agree, adding that I prefer a higher than gates-and-FF's level of
working and don't mind that a tool is forcing a known-to-work design
style on me (IDaSS is geared towards hierarchical, synchronous systems
and actively discourages -but does not completely prohibit- things like
combinatorial loops).
I do get very little feedback from IDaSS users (which can be both a good
and a bad thing ;-) ). I *do* know it's downloaded on average once a day
and that the downloads originate from all over the world. There must be
a whole bunch of people out there playing with it like I do - everyone
is invited!
Greetings from Holland,
Ad Verschueren
Article: 51686I'm not sure if this is the right place to ask this question but you guys seem to know alot about PCI so maybe you can point me in the right direction. I'm building a Data Acquisition board with an Altera Flex 6000 transfering data through a PLX9054 to the PCI bus in DMA mode and I'm trying to test it with DJGPP. What I want to know is how do I find the address for the DMA buffer. Do I define it in the DJGPP program and tell the PLX9054 about it? If so I can't find anywhere to send the address to the PLX9054. Or does the PLX9054 set up the address and buffer, then how does the program find out what this address is? Is there some DMA controller I don't know about involved. Or is the address in the PCI configuration stuff? Thanks PaulArticle: 51687
>Sure, any bad designer can create an unreadable design using any set >of tools. (or even a good designer who wants his design to be >unreadable as Job Security). What I an saying is that it IS easier to >make HDL code understandable than making schematic design, because you >are working at a higher level of abstraction: you don't have to >examine a mess of gates and FFs to understand what this counter/FSM is >supposed to do. I don't see how HDLs automatically work at a higher level of abstraction. I can put a whole CPU in a single box on schematics. Is that high enough? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 51688
Hi there all, I'm a VHDL learner, and looking for some VHDL source. Is there anyone who have a 32bit ALU with floating point written in VHDL? Or can you tell me where on the web I can find it? Thank you VaxenTArticle: 51689
> Anyhow, from the information you provided, here is my thoughts > about your problem. > I feel like the problem you are having is that the Spartan-II is not > being configured fast enough to catch RST# assertion. > As you know, Conventional PCI (That is, PCI 2.x) says devices have to be > active (In case of an SRAM FPGA, completely configured) within 100ms. > During that period, RST# is asserted, so that PCI devices can initialize > their FFs. > If the Spartan-II isn't getting configured within that period, it will > likely miss the RST# assertion, therefore, the design won't get > initialized correctly. Kevin, since PCI v2.2 the spec was changed (to allow larger programmable devices to be configured?). I've had a quick flick through v2.3 and can't find the exact details, but devices now have something like 2^25 clock cycles guaranteed before the first access. Having said that I'm not sure if it dictates a minimun time before reset is de-asserted so if you were using the rising edge of reset to reset state machines etc you could miss it if it was de-asserted before your device was configured. Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 51690
"Austin Franklin" <austin@da98rkroom.com> writes: > BTW, how do you think the writers of compilers decide what the output should > be, and then check it? Modern compilers have so many optimizations that generally the only sure way to tell what the output will be is to run it through. And yes, I *have* spoken to real-world compiler writers about this. The spec is that a valid program gets translated into object code that has the desired effect. This is verified using large regression test suites. The design of any given optimization is such that the transformation will preserve invariants. Thus it is not essential to have a spec for what the output of the compiler will be, but rather what things it may do. However, there are so many possibilities for what might happen that it is impractical to say "if you write an if statement that tests the third integer component of a record, and the else portion contains an assigment of a local float variable from a literal followed by continue statement, you will get the following code...". For some early C compilers, back in the 1970s and early 1980s, the output was fairly predictable. That is no longer true for any mainstream C compilers, nor for compilers for most programming languages.Article: 51691
Eric, > > BTW, how do you think the writers of compilers decide what the output should > > be, and then check it? > > The spec is that a valid program gets translated into object code that > has the desired effect. This is verified using large regression test > suites. How do you know what the "desired effect" is, if no one specified it in the first place? > The design of any given optimization is such that the transformation will > preserve invariants. You are combining optimization with compilation. They are different. > Thus it is not essential to have a spec for what > the output of the compiler will be, but rather what things it may do. I don't know what you mean by "what things it may do", is that not it's "output"? What else can "it do"? Hopefully my laundry ;-) > However, there are so many possibilities for what might happen that it > is impractical to say "if you write an if statement that tests the third > integer component of a record, and the else portion contains an assigment > of a local float variable from a literal followed by continue statement, > you will get the following code...". Again, I disagree. Pre-optimized processing is quite deterministic, as is optimization, but with optimization you globalize the input. > For some early C compilers, back in the 1970s and early 1980s, the output > was fairly predictable. That is no longer true for any mainstream > C compilers, nor for compilers for most programming languages. I agree, but that doesn't negate my original premise, or it's value. AustinArticle: 51692
>For some early C compilers, back in the 1970s and early 1980s, the output >was fairly predictable. That is no longer true for any mainstream >C compilers, nor for compilers for most programming languages. It's even worse than that. Many (most?) assemblers for complicated ISAs will rearrange your code to be helpful. Most of the time they make things go faster. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 51693
Hi Paul, This isn't an easy, straightforward question, at least to me...and I've done a lot of work with the PLX DMAs. Sounds to me like you might want to review the driver source provided in the PLX SDK, and read a bit more of the spec for the PLX. Your question is pretty open-ended. I don't know what DJGPP is, and you didn't say what the source/destination of your DMA is over the PCI bus....it can be another PCI card, or system memory. What OS are you using? How a DMA engine typically gets set-up, is the application/driver (some code running on the main CPU) figures out the address...and if it's system memory, it does some request to the OS to get that chunk of memory, and it gets a returned pointer to either that memory, or a data structure. Also, typically, that address has to be translated from virtual to physical space... That address gets programmed into the 9054 DMA...but...the OS may return a data structure that contains a linked list of addresses, if it didn't allocate the memory in one chunk...you have to set-up the PLX DMA for that. If you'd come up with some more specific info...or at least let me know the answers to the questions I have above, I might be able to help you more. Austin "Paul Cousoulis" <paulcsouls@worldnet.att.net> wrote in message news:3E2AEB19.BF0C5DF1@worldnet.att.net... > I'm not sure if this is the right place to ask this question but you > guys seem to know alot about PCI so maybe you can point me in the right > direction. > > I'm building a Data Acquisition board with an Altera Flex 6000 > transfering data through a PLX9054 to the PCI bus in DMA mode and I'm > trying to test it with DJGPP. What I want to know is how do I find the > address for the DMA buffer. Do I define it in the DJGPP program and tell > the PLX9054 about it? If so I can't find anywhere to send the address to > the PLX9054. Or does the PLX9054 set up the address and buffer, then > how does the program find out what this address is? Is there some DMA > controller I don't know about involved. Or is the address in the PCI > configuration stuff? > > Thanks > PaulArticle: 51694
Hi Austin I guess part of my problem is that I'm not using the PLX SDK. DJGPP is a protected mode DOS C compiler. I've been using it to test my FPGA design. I can read and write the PLX configuration address space and I can access the local bus to write the registers in the FLEX 6000. I need an address and a buffer for the DMA. Thanks Paul Austin Franklin wrote: > > Hi Paul, > > This isn't an easy, straightforward question, at least to me...and I've done > a lot of work with the PLX DMAs. Sounds to me like you might want to review > the driver source provided in the PLX SDK, and read a bit more of the spec > for the PLX. Your question is pretty open-ended. I don't know what DJGPP > is, and you didn't say what the source/destination of your DMA is over the > PCI bus....it can be another PCI card, or system memory. What OS are you > using? > > How a DMA engine typically gets set-up, is the application/driver (some code > running on the main CPU) figures out the address...and if it's system > memory, it does some request to the OS to get that chunk of memory, and it > gets a returned pointer to either that memory, or a data structure. Also, > typically, that address has to be translated from virtual to physical > space... That address gets programmed into the 9054 DMA...but...the OS may > return a data structure that contains a linked list of addresses, if it > didn't allocate the memory in one chunk...you have to set-up the PLX DMA for > that. > > If you'd come up with some more specific info...or at least let me know the > answers to the questions I have above, I might be able to help you more. > > Austin > > "Paul Cousoulis" <paulcsouls@worldnet.att.net> wrote in message > news:3E2AEB19.BF0C5DF1@worldnet.att.net... > > I'm not sure if this is the right place to ask this question but you > > guys seem to know alot about PCI so maybe you can point me in the right > > direction. > > > > I'm building a Data Acquisition board with an Altera Flex 6000 > > transfering data through a PLX9054 to the PCI bus in DMA mode and I'm > > trying to test it with DJGPP. What I want to know is how do I find the > > address for the DMA buffer. Do I define it in the DJGPP program and tell > > the PLX9054 about it? If so I can't find anywhere to send the address to > > the PLX9054. Or does the PLX9054 set up the address and buffer, then > > how does the program find out what this address is? Is there some DMA > > controller I don't know about involved. Or is the address in the PCI > > configuration stuff? > > > > Thanks > > PaulArticle: 51696
"Paul Cousoulis" <paulcsouls@worldnet.att.net> wrote in message news:3E2B40E7.5B7EE005@worldnet.att.net... > Hi Austin > > I guess part of my problem is that I'm not using the PLX SDK. DJGPP is a > protected mode DOS C compiler. I've been using it to test my FPGA > design. I can read and write the PLX configuration address space and I > can access the local bus to write the registers in the FLEX 6000. I need > an address and a buffer for the DMA. What OS? I assume DOS? If so, your application should do a malloc and get the address, with DOS there is no need to do virtual to physical address translation, I do not believe...and you should be all set. AustinArticle: 51697
"Hal Murray" <hmurray@suespammers.org> wrote in message news:v2m6oih9auhcae@corp.supernews.com... > Many (most?) assemblers for complicated > ISAs will rearrange your code to be helpful. Most of the time they > make things go faster. Hi Hal, Won't the rearrangement be deterministic though? I mean, it doesn't just "guess" at what will work, there has to be some set of rules that it goes by... AustinArticle: 51698
"Hal Murray" <hmurray@suespammers.org> wrote in message news:v2lvoj4eb6aif5@corp.supernews.com... > >Sure, any bad designer can create an unreadable design using any set > >of tools. (or even a good designer who wants his design to be > >unreadable as Job Security). What I an saying is that it IS easier to > >make HDL code understandable than making schematic design, because you > >are working at a higher level of abstraction: you don't have to > >examine a mess of gates and FFs to understand what this counter/FSM is > >supposed to do. > > I don't see how HDLs automatically work at a higher level of > abstraction. > > I can put a whole CPU in a single box on schematics. > Is that high enough? Hi Hal, I agree...and was going to say that in fact...but you beat me to the punch. I think what is meant by that is, that inherently, HDLs offer a higher level of abstraction, such as for state machines, counters etc. Most people think of schematics are single gates or flops, with no level of abstraction...which is probably the MAJOR problem...MOST people simply don't understand how to use schematics effectively. I honestly can't remember a book written on the subject (I personally believe it's just to simple a concept to devote to an entire book though), but there are probably a hundred books written on HDLs...that in it self, may be one of the contributing reasons why HDLs are so popular with chip designers now. Read a book, become an expert! With schematics, you actually have to figure out a lot on your own. AustinArticle: 51699
As does synthesis. Synthesis goes by a set of rules, however when the rules
get sufficiently complex, the exact implemention tht results can be hard to
accurately predict. Such is the case with both modern day C compilers as
well as synthesis tools that are sophisticated enough to be competitive
today. So deterministic in the sense that you get the same results out a
given version with a given input. However if you change the input at all,
the output may change a lot in response to a subtle change because an
alteration in the way the rules are applied to the code. For heavily
pipelined design, which in most cases is what you should be doing for FPGAs,
the resulting circuit is in most cases identical except in the naming of the
LUTs. Where you see significant differences is when you have multiple levels
of logic that are easy to map in different ways. So for more consistent
results, keep the logic down to 4 input LUTs between flip-flops, or use
instantiation. You can also gently nudge the implementation through
judicious use of the syn_keep (or equivalent for other tools) to constrain
certain parts of the combinatorial logic to appear at LUT outputs.
Austin Franklin wrote:
> "Hal Murray" <hmurray@suespammers.org> wrote in message
> news:v2m6oih9auhcae@corp.supernews.com...
> > Many (most?) assemblers for complicated
> > ISAs will rearrange your code to be helpful. Most of the time they
> > make things go faster.
>
> Hi Hal,
>
> Won't the rearrangement be deterministic though? I mean, it doesn't just
> "guess" at what will work, there has to be some set of rules that it goes
> by...
>
> Austin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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