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
On Wed, 24 Nov 1999 15:11:57 GMT, Greg Neff <gregneff@my-deja.com> wrote: >In article <hAo7OGCUqVpuedBjHwKsQ44FTFG5@4ax.com>, > John Larkin <jjlarkin@highlandtechnologySnipThis.com> wrote: >(snip) >> We actually don't spend much time debugging uP code or FPGAs because >of our >> philosophy: design carefully, document and comment thoroughly, check >it before >> you fire it up, and keep it beautiful at all times. I dislike >habitual use of >> simulation because it tends to lead designers toward a hack-and-test >mode, and >> one can never really test quality into anything. So far, we've had >zero >> hardware/software/FPGA bugs in the products we've shipped that have >FPGAs. >> >> Anyway, we do fairly hairy FPGA designs using schematics, and the >stuff comes >> out fast and relatively easy. I just thought *somebody* ought to >express that >> opinion. >> >(snip) > >I think that Ray was commenting on those engineers that use the "burn >and learn" approach to design, which is very risky and unpredictable. >If I understand your comment correctly, you are trying to avoid a >similar "simulate and learn" approach. Although neither is a good >design methodology, I would imagine that it would still be better to >learn at the simulate stage, as opposed to the hardware stage. > >The "correct by design" approach (which is what I think you are >promoting) still requires some sort of method to validate and >verify "correctness". Complete specifications, careful and well >documented designs, and design reviews are obvious requirements to >implement a correct by design methodology. Still, I find it hard to >believe that simulations are not faster and more reliable than manual >analysis when it comes to validating a design. Greg, the final product *must* be thoroughly tested, so this testing is potentially redundant with FPGA simulation. Lots of things can go wrong in the non-FPGA hardware and software, so it seems scairy to me to assume that a product works just because one simulation predicts that it does. If the FPGA design is flat DOA, and you can't even begin to test the final product, you can blame that situation on a) failure to simulate or b) sloppy design, depending on how you feel about these things. But the same applies to the PCB layout, the uP code, and the non-FPGA parts of a design. Without being *too* obnoxious about it, I think that moderately complex FPGA designs can be done efficiently using schematics. If they are designed and checked carefully, any bugs can be found at the product qualification test level (which we are obliged to do anyway) and, if the design and documentation are good, fixed quickly and easily. JohnArticle: 19026
Donald Gillies wrote: > > TCP is an unrealistic thing to implement on an FPGA - no matter what > the time frame, no matter who is doing it. A good TCP has some very > complex sub-algorithms. Not only are you going to need to explain to the person who has already stated that he was involved in an implementation in two Xilinx 4044's that it was just a lucid dream, you're also going to have to convince Seiko that a hardware implementation of moderate size and cost is impossible before they sell too many of their S7600 parts: http://www.seiko-usa-ecd.com/intcir/html/assp/s7600a.html They licensed the technology from iReady (www.iready.com) who claim a 67k gate count for the protocol stack, developed fully in Verilog RTL. However, I do agree that this is an impossible task for a student project. Perhaps a more realistic task would be to buy one of the Seiko chips, and interface it to an affordable FPGA and/or microprocessor to implement a higher-layer protocol such as HTTP? MarkArticle: 19027
Mark Summerfield <m.summerfield@ieee.org> wrote in message news:383C5D6D.DC4E63D5@ieee.org... > that it was just a lucid dream, you're also going to have to convince > Seiko that a hardware implementation of moderate size and cost is > impossible before they sell too many of their S7600 parts: > > http://www.seiko-usa-ecd.com/intcir/html/assp/s7600a.html Depends what you mean by 'hardware implementation'. Do you mean single chip micro using a gate array? State machine that is not quite single chip micro, or 'random logic' with TCP/IP hardwired - no microcode? > They licensed the technology from iReady (www.iready.com) who claim > a 67k gate count for the protocol stack, developed fully in Verilog RTL. > However, I do agree that this is an impossible task for a student > project. Perhaps a more realistic task would be to buy one of the > Seiko chips, and interface it to an affordable FPGA and/or microprocessor > to implement a higher-layer protocol such as HTTP? A better project might be using a FPGA as a s/w configurable co-processor for a standard uP, with (simple) examples of 'C' code being compiled into configuration data for the FPGA to run it in h/w. How simple or complex is entirely up to those doing the project. The nice thing is, the effort is smoothly scalable, from int a+=1; right through to FFTs and upwards. IIRC, Xilinx is/was sponsoring such research in some university. They may well be able to help. DirkArticle: 19028
Have you looked at the Quicklogic core? Impressive... acts hardwired, has lots of block ram, doesn't need a big prom, and I think it is cheaper than anything you will get from Xilinx that will actually hold the core (if you include the big prom). Also, they have a 66MHz 64 bit version (embedded asic). One thing you might look at when you consider PCI cores is whether you need a "backup fifo" or is it implemented in the core. When you get a late TRDY-false does the core save the data in a hidden register or do you have to backup your fifo pointer to send it (there is no way you will be able to stop the fifo from advancing since the signal comes so late). My impression is that Xilinx requires a backup fifo. Also, look carefully at the price of the part once it is big enough and fast enough to hold the core. Bruce Bryan Williams wrote in message <383BA036.7C1188C5@at_smart.net>... >email address is altered to prevent spam. >I'd recommend the part only if you hate yourself and are looking for a >reason to end it all ;) > >Jokes aside, we've been trying to use this part, and there's a lot of pain >involved. Another thread regarding >Lucent parts brings up many of these points. Have you found a proto-board >based on this part? If so, I'd like >to hear about it, but I don't think it exists because I've spent mucho time >looking through all the lists at optimagic >and other sites to no avail. Like someone else pointed out, Xilinx & Altera >make FPGA's and hardly anything else. Lucent makes so >many types of products it would be nearly impossible for one list them all. >Who's gonna try harder? > >We're in the process of getting Xilinx's PCI design kit. One thing I like >about it is the ability to target anything from a cheap Spartan >(is there really any FPGA competition for Spartan's market?) to the biggest >Virtex. I'll know more when it's in hand. > >Lucent's tools are now behind the times. Xilinx bought Neocad, old news, but >the Lucent back-end tools haven't changed a lot since then. >A bit rough around the edges. I'm not sure how Lucent explains their >continuing rights to the NeoCAD software since the Xilinx buyout. I >think they took the existing codebase and found new programmers to take over >the code and go in their own direction, but I'm speculating. > >A problem you'll immediately find is that so far as I can tell the OR3TP12 >is EXCLUSIVELY FOR VHDL/Verilog. That's the way the >core parameters are passed and it's your only option. The core setup tool >is a pain too since you can't save your settings to revise them later. >It fleshes out a VHDL/Verilog template and you can't go back to the GUI to >tweak settings later. Write them down ! We're using Synplify for the >VHDL, FYI. > >There's a lot of nifty things the hardwired core allows you to do, but >there's also the drawback of it being considerably more effort for them to >roll >out new chips. Your only option right now is the pared-down OR3C/T55 -sized >device (sans about 4 rows for the PCI core) with other parts "coming soon >now" >for quite some time now. Our local apps engineer went back to the plant to >"help roll out the next device" or something, which left us without >good support. The hardwired core has many bugs, and the downside of these >bugs is that it's not a simple fix being hardwired and all. > >The core setup software had a bug we were stuck with for quite some time >before receiving an update -- the BYTES were OUT OF ORDER in the 32-bit >words. >How the hell do you miss something like that in testing? Luckily, it WAS >software. > >My guess is that if you go with the part you will feel very alone with >whatever problems you come across. We sure do. > >One good way to judge your FPGA vendor: go see how many application notes >they have. Lucent's got maybe 10 or 20 total on the web. Xilinx has probably >a thousand >or more scattered across the Xcell Journal and general app notes. I like >that. > >The Xilinx PCI design kit comes with a board based on the core and a >reference design. PCI is complicated as hell and that reference can save >MONTHS. >Something to think about! >BW > >Edward Wallington wrote: > >> Hi, >> has anyone put a design into production using the OR3TP12 on a card in a >> PC? >> (this is Lucent's part FPGA, part hardwired ASIC PCI core) >> >> Which synthesis route / tools did you use? >> Any gotcha's ? Did it work perfectly? >> >> Thanks >> >> Ed. >> >> -- >> Edward Wallington - Chief Hardware Engineer >> Cambridge Research Systems Ltd. >> Tel: +44 (0)1634 720707 Fax: +44 (0)1634 720719 >> http://www.crsltd.com >Article: 19029
log wrote: > > This might not be strictly an FPGA question, but does anyone know if it is > currently possible to get obselete microprocessors emulated on fpgas or > other platforms. I need a seamless cross over from an old one time 8749 to > something which looks electronically the same when in circuit. It is possible, but not practical. The 8749 should still be procurable, and even on upward slope of a bathtub price curve, will cost less than a FPGA. FPGA's do not come in DIP40 packages, so a adaptor PCB is needed, with a min of QFP.fpga + Serial Loader PROM, and possibly a MEMORY chip for CODE storage. A better approach is to use a 89C51 to emulate a 8749, when they finally dry up completely, and even these are 99% compatible. We have done macros to allow ASM48 -> ASM51 porting. - jg -- ======= Manufacturers of Design Tools for uC and PLD ===== * IceP2051 - Full Speed ICE, for 1K,2K,4K 20 Pin FLASH controllers * OptoISP - Safe, fast In System Program of 89S, 90S, 17C devices => http://www.DesignTools.co.nz/winner51.htm for highlightsArticle: 19030
I have to interface a regular micro to an UTOPIA 1.0 Interface using a FPGA. I've tried to find out an application note describing this kind of interface on different FPGA Web Site, but it seems that today, everybody has IP stuff, and you have to buy it (it's quite expensive...) Is someone there has any reference or good URL about that, Thanks, -- FranckArticle: 19031
In article <S0Y8OAj5xsgDRoKM1sl4YlEpHfzg@4ax.com>, John Larkin <jjlarkin@highlandtechnologySnipThis.com> wrote: > Greg, > > the final product *must* be thoroughly tested, Yup, you gotta test every "shall" in the spec. > so this testing is potentially > redundant with FPGA simulation. True. > Lots of things can go wrong in the non-FPGA > hardware and software, Murphy is an optimist. > so it seems scairy to me to assume that a product works > just because one simulation predicts that it does. I don't think we are talking about making that kind of assumption, or saying that FPGA functionality can be extended to imply system functionality. Don't get me wrong here, I don't entirely disagree with your opinion. Certainly, a simulation is no good if the stimulus does not properly mimic what actually is present in the system (garbage in, garbage out). This is a *big* problem with simulation (just ask the SPICE guys). > If the FPGA design is flat > DOA, and you can't even begin to test the final product, you can blame that > situation on a) failure to simulate or b) sloppy design, depending on how you > feel about these things. But the same applies to the PCB layout, the uP code, > and the non-FPGA parts of a design. > Hmmm. I don't think that I'm saying that simulation is a replacement for sound design. I think the "correct by design" approach is the best way to go, since there is less time spent on fixing things later. Still, I have been doing this stuff for too long to believe that anyone can produce a 25-page FPGA schematic, including state machines, digital PLLs, etc., and expect it to run right out of the chute. > Without being *too* obnoxious about it, No problem, I like a good discussion :) >I think that moderately complex FPGA > designs can be done efficiently using schematics. If they are designed and > checked carefully, any bugs can be found at the product qualification test > level (which we are obliged to do anyway) and, if the design and documentation > are good, fixed quickly and easily. > I mostly agree with this statement. I am very comfortable with schematic entry (I use Viewlogic), which is why I am questioning the need to go to VHDL. I am not convinced that I need VHDL, which is why I posted the set of questions. I appreciate your opinions on this. However, the VHDL question is separate from the simulation issue that we seem to be debating. I am convinced that running simulations on my schematic based designs helps to validate portions of a design that can't be tested, such as forcing a state machine to an illegal state. Also, I know that simulations have saved me lots of time in troubleshooting quirky problems, where I needed to have a high degree of visibility into the logic. Simulation is not, and never will be, a replacement for proper design methodology or thorough system testing. I view simulation as another tool in my toolbox, but I wouldn't want give up that tool. For example, I had a packet converter design that was experiencing a bit error rate of about 1 in 100,000. On the test bench, everything looked perfect on the instrumentation. I ran some simulations, and found that during entry I had incorrectly wired a gate that was there to handle a low-probability boundary condition. I fixed the gate, and the bit errors were gone. I would have *never* figured that out with a scope or logic analyzer, since I had no access to that internal logic on the test bench. Bottom line is that I agree with your statements about schematic design methodology, but I don't agree that simulation is a bad thing (if it is used properly). -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19032
On Thu, 25 Nov 1999 03:51:48 GMT, Greg Neff <gregneff@my-deja.com> wrote: |However, the VHDL question is separate from the simulation issue that |we seem to be debating. I am convinced that running simulations on my |schematic based designs helps to validate portions of a design that |can't be tested, such as forcing a state machine to an illegal state. Greg, that statement intrigued me. Around here, we've debated some about the 'illegal state' issue. The positions are... 1. Any state machine should be able to walk its way out of any illegal state into a correct sequence or 2. Bull! If something's impossible, you don't need to worry about it. If a state machine gets into an impossible state, then the FPGA is broken. After all, if software gets into an impossible state (like the PC in the middle of a data table or somesuch) then it's crashed. (sorry about bringing up an even-less relevant point!) Ideas? John == A little nonsense now and then, is cherished by the wisest men. - Willy WonkaArticle: 19033
John Doe wrote: > > VHDL or Verilog is the only way to go for many reasons. > > 1. Re-use is as simple as cut and paste (almost) As many have pointed out in these threads, re-use is in many ways still a pipe dream. It works well for a limited number of functions if someone takes the time to write a fully parameterized (and usually FPGA vendor-specific) library. Then you still usually have to check what the synthesis tool spit out to make sure it didn't do something stupid. Cut and paste, or copying and modifying modules, is unfortunately the way it usually goes in my experience. But that's not the way re-use was envisioned by the VHDL creators. Look at the IP market. A loser business if there ever was one, and one reason is that most designs require some kind of special tweak to most common functions. The other big reason most companies don't buy IP is that they want to own their technology, and that comes into play at the individual designer level as well. How can I call this my design and be responsible for maintaining it if someone else designed half of it? > 2. Portability - most schematic entry tools that I know of use vedor > specific libraries (I definately do not recommend this). I really don't buy the portability argument for FPGAs. To really take advantage of an architecture you end up with a lot of vendor-specific code. Most code is portable between simulation tools as long as the vendor libraries are fully compliant, but a lot of code is also Synthesis tool-specific. Overall this argument fails for FPGAs. > 3. Simulation was made so much easier (this alone is an excellent reason to > change over). Agreed. > snip Personally I don't think detailed knowledge of the language is needed to use an HDL effectively. The real value that a design engineer adds is at a higher level than writing code (or entering a schematic). The real work is at the system level, writing a good spec and doing the high-level design. Once that's done a monkey can code it. Writing a good test bench and writing device models requires thorough knowledge of the language. Design entry, in my opinion, does not. Once you have an intelligent partition (part of the high-level design process), as long as you format your code so it is readable, add reasonable comments, and follow general synchronous design rules, you can do some serious damage with a small subset of the language. If you're a good designer at the schematic level you'll be a good designer using an HDL. If you want to ease the transition hire an expert to write your test benches until you're comfortable with the methodology. RJSArticle: 19034
Hi all, Since a quarter of a year I discover the beatiful world of AHDL and VHDL. Until now everithing worked fine. But now I would be very grateful for a little help. Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured by Ing. Buero Lindmeier) in my hands. This evaluation board contains an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the ALTERA MAX+plusII (v 9.1) software......no problem to this point. Two weeks ago I purchased an configuration EPROM (EPC2LC20), which could optional plugged into my evaluation board.I set up the MAX plus JTAG chain due to the requirements (as far as I would say), performed an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus detected the additional device in the JTAG Chain. But when I try to Program the .pof file to the EPROM I get the message: Unrecognized device or socked empty. What am I doing wrong????? From my point of view I changed nearly every parameter in the MAX plus setup. I hope there is somebody out there, who could give me a hint how to get this EPROM configured. MANY THANKS IN ADVANCE!!! Best regards, VolkerArticle: 19035
Hi all, Since a quarter of a year I discover the beatiful world of AHDL and VHDL. Until now everithing worked fine. But now I would be very grateful for a little help. Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured by Ing. Buero Lindmeier) in my hands. This evaluation board contains an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the ALTERA MAX+plusII (v 9.1) software......no problem to this point. Two weeks ago I purchased an configuration EPROM (EPC2LC20), which could optional plugged into my evaluation board.I set up the MAX plus JTAG chain due to the requirements (as far as I would say), performed an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus detected the additional device in the JTAG Chain. But when I try to Program the .pof file to the EPROM I get the message: Unrecognized device or socked empty. What am I doing wrong????? From my point of view I changed nearly every parameter in the MAX plus setup. I hope there is somebody out there, who could give me a hint how to get this EPROM configured. MANY THANKS IN ADVANCE!!! Best regards, VolkerArticle: 19036
Dirk Bruere wrote:
> Depends what you mean by 'hardware implementation'. Do you mean single chip
> micro using a gate array? State machine that is not quite single chip micro,
> or 'random logic' with TCP/IP hardwired - no microcode?
Well, I haven't seen iReady's code, but if it's written entirely in
Verilog RTL, requires 67k gates, and is technology and library independent
(all their claims), then I think it qualifies as a hardware implementation.
It includes TCP, UDP, IP and PPP implementations, and a serial interface.
It also appears to require 20k of external memory as a buffer for packets.
And an external microprocessor (or equivalent) to actually control it.
I would assume that it contains many state machines, and a lot of "random
logic". And maybe some simple microcode for some of the state machines,
I guess. I don't actually understand the distinction you're trying to
draw -- all these are valid digital design techniques which result in
"hardware".
You can decide for yourself if you think it qualifies as a hardware
implementation. There's more information on their web site:
http://www.iready.com/products/internet_tuner.html
Mark
Article: 19037"Dirk Bruere" <artemis@kbnet.co.uk> writes: (snip) >Depends what you mean by 'hardware implementation'. Do you mean single chip >micro using a gate array? State machine that is not quite single chip micro, >or 'random logic' with TCP/IP hardwired - no microcode? Oh no, the microcode myth again. Is there something wrong with it if it is microcoded? It is possible to build slow vertically microcoded processors, but it is also possible to build fast horizontal microcoded processors. Many processors could be build to run about as fast with about the same amount of logic microcoded or hardwired. However, for TCP/IP I would suggest a simple vertical (small instruction word) processor, almost a simple FSM (state machine) implementation. In FPGA with an external ROM it might not be bad. You could even write a C compiler for it! -- glenArticle: 19038
Tom McLaughlin wrote: > > Michael, > Thanks for the advice. I'm still having problems. We didn't design the board > which is one of the problems. One thing I noticed is that you guys put the > config pins on "000" for configuration. We put them on 101 for "JTAG mode" I > thought that is what it had to be on to config through the JTAG port. Again, > the JTAG programmer software says that the device is programmed, but it is like > the device never goes through it's startup sequence. DONE never goes high. > When I have access to the board again, I'll try configuring with the pins on > "000". > > The other thing I noticed is that you mention the program pin. We don't > manipulate this pin. Should we??? You mention that it is for PROM > configuration. Again, we are trying to program via JTAG. Should we have to > pull the PROGRAM pin low and then let it go high to program via JTAG??? > Tom > > > > > > > Hi Tom, > > > > We'v done JTAG configuration of virtex > > XCV300 with XChecker and also with a > > selfmade interface for parallelport > > (Application Note Xilinx). There were no > > problems. I think the pullup on init is > > ok (we have the same). > > I will tell you the other configuration > > pins for orientation: > > > > Hi Tom, I don't know exactly if the program pin is necessary in your BSCAN-Mode (101). I'v read in the Virtex Manual and found on side 21 a description of configuration sequence. I think if you hold program low the FPGA will do nothing exept resetting its memory. If then program goes high the FPGA is ready for configuration. Our program Signal is everytime available (low, high after 100ms) in PROM or JTAG Configuration. Maybe this is the case it works? I hope this will help You, MichaelArticle: 19039
FACULTY OF MATHEMATICS, COMPUTER SCIENCE, PHYSICS AND ASTRONOMY
University of Amsterdam
has an opening for a
PH.D. STUDENT
for 38 hours per week (ref. nr. 15075)
The Computer Architecture & Parallel Systems Group at the Faculty of
Mathematics, Computer Science, Physics and Astronomy of the University of
Amsterdam has an opening for a Ph.D. student in the area of embedded computer
architecture modelling & simulation. The Ph.D. student will participate in the
SESAME (Simulation of Embedded System Architecture for Multilevel Exploration)
project which aims at the development of a simulation workbench for the design
space exploration of programmable embedded media systems. This project, which is
funded by the Dutch government as part of the project called 'Methods and
Architectures for Programmable Embedded Media Systems', is performed in close
collaboration with Philips Research Laboratories and Delft University of
Technology.
TASKS: research on and development of methods and techniques for abstract
computer architecture simulation in the context of embedded systems.
REQUIREMENTS: * M.Sc. in computer science or electrical engineering
* decent knowledge of computer architecture
* preferably (not a must) some expertise in the field of
(computer architecture) simulation
The Ph.D. student will obtain a temporary research position for four years
at the Faculty of Mathematics, Computer Science, Physics and Astronomy of
the University of Amsterdam, for 38 hours per week. The gross monthly
salary is NLG 2,195.- for the first year, growing up to NLG 3,919.- for the
last year, PLUS an extra allowance. The holiday allowance will be 8% of the
annual income.
INFORMATION on our group and the ongoing research: www.wins.uva.nl/research/arch/
APPLICATION: Applications, quoting job reference number (15075) and marked
'confidential', should include a curriculum vitae, a list of course grades
and a list of publications, and should be sent to dr. A.D. Pimentel, University
of Amsterdam, Faculty of WINS, Kruislaan 403, 1098 SJ Amsterdam, The Netherlands.
Inquiries and applications sent by e-mail (ASCII or postscript) should be directed
to andy@wins.uva.nl
--
Andy Pimentel x #define R(x,y) (x<<y|(x<<y&32)>>5)&31
Computer Architecture & X :x: main(i){putchar(i+64);if(~i&16)if(~0\
Parallel Systems Group, |X| x +i&&~3+i)main(R((~i&15),2));else mai\
University of Amsterdam X n(R((i|i<<1|i<<2),1));else puts("");}
Article: 19040
Andy Peters wrote in message <81h3o8$17ab$1@noao.edu>...
>Filip S. Balan wrote in message <81g8ar$h47$1@strelovod.uni-mb.si>...
>>Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>...
>>>Filip S. Balan wrote in message <81dm75$jt9$1@strelovod.uni-mb.si>...
>>>>>>**Symplify (simulates the HDL design fine all the time)
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>>I missed 1 SW:
>>>>Symplify & Aldec Active-VHDL (simulates the HDL design fine all the time)
>>>
>>>
>>>Did you use timing constraints and are they being met?
>>>
>>
>>
>>Think it is not important. The input of the shift register is at one input
>>pin
>>and the output of the shift register (last bit) at another (output) pin. A
>>logic
>>"1" should after some time (Tclk * N+eventual timing problems) cause a
>logic
>>"1" and a "0" a "0".
>>I used this simple TEST design just for this insensibility (if the delay is
>>not important to me).
>>But the output is sometimes (in dependence of cell positions) stuck at "0"
>>or "1" (it does not change)!
>
>perhaps if you post your code...
>
>
>--
>-----------------------------------------
>Andy Peters
>Sr Electrical Engineer
>National Optical Astronomy Observatories
>950 N Cherry Ave
>Tucson, AZ 85719
>apeters (at) noao \dot\ edu
>
>The secret of Slurm is on a need-to-know basis.
>
>
>
Hope names in the slovenian language aren't to hard:
ura = clock
vhod = input
izhod = output
regards
Filip S. Balan
The following is the code for a 16-bit shifter block.
********************************************************
LIBRARY ieee;
USE ieee.std_logic_1164.all;
entity pom_blok is
port
(
ura, reset, vhod: in std_logic;
izhod: out std_logic
);
end pom_blok;
architecture pom_blok of pom_blok is
component sh_reg
port
SHIFTOUT : out std_logic;
CLK : in std_logic;
RN : in std_logic;
SHIFTIN : in std_logic
);
end component;
SIGNAL tmp_sig_1: std_logic;
SIGNAL tmp_sig_2: std_logic;
SIGNAL tmp_sig_3: std_logic;
SIGNAL tmp_sig_4: std_logic;
SIGNAL tmp_sig_5: std_logic;
SIGNAL tmp_sig_6: std_logic;
SIGNAL tmp_sig_7: std_logic;
SIGNAL tmp_sig_8: std_logic;
SIGNAL tmp_sig_9: std_logic;
SIGNAL tmp_sig_10: std_logic;
SIGNAL tmp_sig_11: std_logic;
SIGNAL tmp_sig_12: std_logic;
SIGNAL tmp_sig_13: std_logic;
SIGNAL tmp_sig_14: std_logic;
SIGNAL tmp_sig_15: std_logic;
SIGNAL tmp_sig_16: std_logic;
SIGNAL tmp_sig_17: std_logic;
BEGIN
tmp_sig_1 <= vhod;
izhod <= tmp_sig_17;
r1:sh_reg port map (
SHIFTOUT => tmp_sig_2,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_1
);
r2:sh_reg port map (
SHIFTOUT => tmp_sig_3,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_2
);
r3:sh_reg port map (
SHIFTOUT => tmp_sig_4,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_3
);
r4:sh_reg port map (
SHIFTOUT => tmp_sig_5,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_4
);
r5:sh_reg port map (
SHIFTOUT => tmp_sig_6,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_5
);
r6:sh_reg port map (
SHIFTOUT => tmp_sig_7,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_6
);
r7:sh_reg port map (
SHIFTOUT => tmp_sig_8,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_7
);
r8:sh_reg port map (
SHIFTOUT => tmp_sig_9,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_8
);
r9:sh_reg port map (
SHIFTOUT => tmp_sig_10,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_9
);
r10:sh_reg port map (
SHIFTOUT => tmp_sig_11,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_10
);
r11:sh_reg port map (
SHIFTOUT => tmp_sig_12,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_11
);
r12:sh_reg port map (
SHIFTOUT => tmp_sig_13,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_12
);
r13:sh_reg port map (
SHIFTOUT => tmp_sig_14,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_13
);
r14:sh_reg port map (
SHIFTOUT => tmp_sig_15,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_14
);
r15:sh_reg port map (
SHIFTOUT => tmp_sig_16,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_15
);
r16:sh_reg port map (
SHIFTOUT => tmp_sig_17,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_16
);
end toplevel;
Article: 19041In article <383AE573.C80AF8FE@arl.wustl.edu>, As far as I know, the state of the mode pins does not matter. On my own board the mode can be either 111 or 110 (slave serial or selectmap) and in either state can be programmed over JTAG. I do notice that if the device is already configured, DONE does not change. I suspect that the configuration over JTAG is a partial one. I always have INIT pulled up because the device will indicate an error by pulling it low. PROG does not have to be toggled to get JTAG to work. Tom McLaughlin <tomm@arl.wustl.edu> wrote: > Michael, > Thanks for the advice. I'm still having problems. We didn't design the board > which is one of the problems. One thing I noticed is that you guys put the > config pins on "000" for configuration. We put them on 101 for "JTAG mode" I > thought that is what it had to be on to config through the JTAG port. Again, > the JTAG programmer software says that the device is programmed, but it is like > the device never goes through it's startup sequence. DONE never goes high. > When I have access to the board again, I'll try configuring with the pins on > "000". > > The other thing I noticed is that you mention the program pin. We don't > manipulate this pin. Should we??? You mention that it is for PROM > configuration. Again, we are trying to program via JTAG. Should we have to > pull the PROGRAM pin low and then let it go high to program via JTAG??? > Tom > > > > > > > Hi Tom, > > > > We'v done JTAG configuration of virtex > > XCV300 with XChecker and also with a > > selfmade interface for parallelport > > (Application Note Xilinx). There were no > > problems. I think the pullup on init is > > ok (we have the same). > > I will tell you the other configuration > > pins for orientation: > > > > > > -- ----------------------------- Alpha Data ----------------------------- Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19042
> We are using Spartan-XL and we intend to use TWO individual resets > in the chip. We wonder if one reset can be assigned to the dedicated > reset routing resources and the other one to the normal routing > resources. We are using Synplify v5.08a, M1.5 and Verilog. > > We have looked at the Synplify and M1.5 manuals, and following things > came out: > > 1. In the Xilinx manual "Synthesis and Simulation Design Guide", page > 4-9, in the first paragraph: > > "XC4000 and Spartan devices have a dedicated Global Set/Reset > (GSR) net that you can use to initialize all CLBs and IOBs. When the > GSR is asserted, EVERY flip flop in the FPGA is simultaneously preset > or cleared. You can access the GSR net from the GSR pin on the > STARTUP block or the GSRIN pin of the STARTBUF (VHDL)." > This is correct. > 2. In the Synplify User Guide book, at the section "Xilinx FPGA Support", > at the item "Startup Block for XC4000 and XC5200", 3rd paragraph: > > "If multiple resets are used in the design, then Synplify will not > automatically create a startup block in GSR. If you still want one > of the reset signals to be used for GSR then you will need to > manually instantiate a STARTUP_GSR module in your design source file." > > From 1, I understand that it is impossible to use two resets one of which > I want to dedicate to GSR routing, because when GSR is asserted, ALL > the flip flops in XC4000 and Spartan will be resetted, some of which > actually have their own individual reset signal, which is not using > GSR routing but normal routing. > If you use the dedicated GSR net, then ALL flip-flops will be reset/preset, regardless of what other reset/presets they have. If I understand correctly, you have some flip-flops which will be reset/preset by one input, and some which will be reset/preset by another input but no flip-flops which will be reset/preset by both. If this is the case, then you can't use the GSR net at all. > From 2, I understand that it is possible to use two resets and one > reset can be asserted to GSR routing and the other one must be used then > in normal routing. But 2 is correct only for XC4000 devices, since > the item is "Startup Block for XC4000 and XC5200", there is not the > word "Spartan" at the header title of the item. > I guess that this is a limitation of Synplicity. (comments from Synplicity users?). I think what they'te talking about here is the case when all flip-flops are reset/preset by the GSR net and some flip-flops have an extra reset/preset condition which will reset/preset them at other times. It is possible use the startup block in Spartan devices - use the XC4000/Spartan family library. > If Xilinx is true, then I conclude that when I want to use more than > one reset in Spartan or XC4000, then routing will be worse, since > I mustn't use GSR usage for a correct operation and the resets will > use normal routing resources. That will make the routing more difficult. I think this is the case. > If Synplify is true, then I conclude that when I want to use more > than one reset in XC4000 and XC5200, and when I want to assign one > of the two reset signals to the GSR routing, then routing will be > used efficiently. > > Which is correct? > > Utku > > In summary, if you use the startup block (either by instantiating it or inferring it), the GSR net will reset/preset ALL flip-flops. Remember that the GSR net will reset/preset the flip-flops to their post-configuration state. Mark Harvey. > _____________________________________________________________ > Deja.com: Before you buy. > http://www.deja.com/ > * To modify or remove your subscription, go to > http://www.deja.com/edit_sub.xp?group=comp.arch.fpga > * Read this thread at > http://www.deja.com/thread/%3C3833D2A3.1BD2146F%40netas.com.tr%3E Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19043
Where I could find information on realizations of CIC filters supposed from E.B. Hogenauer in FPGA? Thank you. Claudio Casagrande e-mail:mariotto@libero.itArticle: 19044
Hi, I'm wondering how Leonardo syntheses async latches. process (.......) if A=2 then Alatch<='1'; elsif A=5 then Alatch<='0'; end if end; Ever if I implement something like this, Xilix alliance say " clock using non dedicated resources found.... It is not good design praxis." Now I have looked in RTF viewer from Leonardo. I have not found Alacht latch!!!!!!!!!!!!! 1.Can anybody explain me, where is my latch 2. Does it in principaly normal design praxis to use level sensitive latches? * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!Article: 19045
Can anybody tell me how it is possible to specify the F or G LUT for the LUT4 symbol? Is there anyway of doing it in the Virtex device?Article: 19046
Thanks to everyone that has posted in this thread so far. My reason for my original posting was not to recommend alternative solutions, but rather to find out what experience of the Lucent OR3TP12 part other people have. We are just putting into production a "visual stimulus generator" (basically a graphics card for medical eye research, I won't bore you with the details) - based around the Lucent chip on a 32bit PC pci bus, target mode only. Our system basically works, but we get stability problems in some PC's (my guess is that it is chipset dependent, but there could be other factors at play). This can appear as lost / corrupted reads or writes. The workarounds we have found are: PCM: (this may also be applicable to a problem mentioned in another thread) Lucent appears to have recently changed their mind about the values to put in the register that configures the PLL to operate over a given range of frequencies. The software (9.35) I think has not incorporated these changes, so the answer is look up the value in the latest orca3 fpga data sheet, then look up what values of frequency in the old datasheet give the same value value. Then set the constraint for the PLL with this frequency (which in our project was significantly higher). This has worked for 2 date codes of the OR3TP12. I only have experience of the PLL mode though. Fclk: (fifo clocks) we suspect there is a problem if the fifos are clocked with a signal that is slow (10MHz) w.r.t. the pci bus. The core seems to get tangled up with a subsequent transaction. You get target ready keep going low. Answer: clock it quicker! There also appears to be issues if you leave a dead clock cycle between requesting the address and requesting the data, (we have a pipeline stage), you end up with a short data phase. This may be a timing problem on our part, but has anyone else found anything similar? One thing lucent don't spell out is that the signals from the core appear / disappear on FALLING edges of the fifo clocks (look carefully at the timing diagrams). Our data was disappearing half a clock before we were registering it! To sum up; we are desperate to ship some boards soon so any help would be greatly appreciated. As a sweetener I will email a copy of our rough 'n ready DOS utility, that uploads a "mcs" file to the lucent via the pci bus to anyone who can offer some hints :<) If anyone wants to buy a board (32bit) with a Lucent on it, get in touch :<) Ed. -- Edward Wallington - Chief Hardware Engineer Cambridge Research Systems Ltd. Tel: +44 (0)1634 720707 Fax: +44 (0)1634 720719 http://www.crsltd.comArticle: 19047
John Larkin wrote: > Greg, > > that statement intrigued me. Around here, we've debated some about the > 'illegal state' issue. The positions are... > > 1. Any state machine should be able to walk its way out of any illegal > state into a correct sequence i would mostly agree. however, for some machines, a periodic reset will accomplish the same thing with the same out of system lost time and quite a bit less effort and hardware (e.g., say zero a state machine for each line read out of an imaging array). you would lose a direct indication though. it depends on the problem and its requirements. designing a state machine so that it never gets into trouble is quite a bit harder. ------------------------------------------------------------- > or > > 2. Bull! If something's impossible, you don't need to worry about it. > If a state machine gets into an impossible state, then the FPGA is > broken. After all, if software gets into an impossible state (like the > PC in the middle of a data table or somesuch) then it's crashed. again, i'll partly agree. if the fpga is busted, then, well, it's busted. trying to design a fault tolerant circuit inside of a single fpga is not easy (and you can't cover them all, but a lot of them). on the other hand, the realities of the system may put your state machine in a bad state. an esd pulse from someone touching the box for commercial/lab systems; a dropout on the power bus from building power dropping or getting funny (commercial, lightning strike) or the system power dropping from some sort of event (military, aerospace, use your imagination); or from cosmic rays or perhaps nuetrons for high altitude civilian or military avionics or spacecraft electronics can put a state machine in a bad state. likely? no. but not impossible and for certain system requirements it may have a requirement to not lock up. anyways, it's an interesting topic, have a good day ================================================= > (sorry about bringing up an even-less relevant point!) > > Ideas? actually, it's a very relevant point and the methods that various synthesizers deal with this problem and one's attempts to cope with it. ------------------------------------------------------------------------ rk The world of space holds vast promise stellar engineering, ltd. for the service of man, and it is a stellare@erols.com.NOSPAM world we ahve only begun to explore. Hi-Rel Digital Systems Design -- James E. Webb, 1968Article: 19048
I'm now in Leonardo RTL viewer.
I can't believe my eyes.
Do you know what Leonrdo makes from this RS-trigger
Hi make clocked latch!!!!!!!!! with S -clock signal!!!!!!!!!!!!!! and
R -async reset signal.
Any comments?
library ieee; use ieee.std_logic_1164.all;
entity LT is
port (o : out std_logic ;
r : in std_logic ;
s : in std_logic );
end;
architecture LT of LT is
begin
process (R,S)
begin
if R='0' then tclr <='0';
else if S='0' then tclr <='1';
end if;
end if;
end process;
end;
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Article: 19049In article <lrc8OPRknqV34Krqe+dRcbWiqbXz@4ax.com>, John Larkin <jjlarkin@highlandSnipSniptechnology.com> wrote: (snip) > > that statement intrigued me. Around here, we've debated some about the > 'illegal state' issue. The positions are... > > 1. Any state machine should be able to walk its way out of any illegal > state into a correct sequence > > or > > 2. Bull! If something's impossible, you don't need to worry about it. > If a state machine gets into an impossible state, then the FPGA is > broken. After all, if software gets into an impossible state (like the > PC in the middle of a data table or somesuch) then it's crashed. > (snip) I tend to agree with #2, but we do work on mission critical designs for transportation and aerospace. These guys aren't happy unless you can show them that you can recover from the impossible. They want to see that the design won't lock up if an illegal state is entered, due to radiation, EMP, etc. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.
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