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
Daniel Jones wrote: > In article <36313CC4.9FD3D096@yahoo.com>, > Rickman <spamgoeshere4@yahoo.com> wrote: > > >Todd Kline wrote: > >> > >> If I care about the state encoding, I don't use enumerated types. I > >> use three different synthesis tools, two different simulators, and > >> target FPGA's and ASIC's. Just the differences in '87 and '93 are > >> enough to drive me nuts. I stay away from all tool specific constructs. > >> For portability, I prefer the following structure: > >> > >> ... > >> > >> signal grants: std_logic_vector(3 downto 0); > >> constant NO_GRANTS: std_logic_vector(3 downto 0) := "0001"; > >> constant VIDEO_GRANT: std_logic_vector(3 downto 0) := "0010"; > >> constant AUDIO_GRANT: std_logic_vector(3 downto 0) := "0100"; > >> constant CPU_GRANT: std_logic_vector(3 downto 0) := "1000"; > >> > >> ... > >> variable next_grant: std_logic_vector(3 downto 0); > >> ... > >> > >> case grants is > >> when VIDEO_GRANT => > >> ... > >> if(expression) then > >> next_grant := VIDEO_GRANT; > >> else > >> next_grant := NO_GRANTS; > >> end if; > >> ... > >> when AUDIO_GRANT => > >> ... > >> when CPU_GRANT => > >> ... > >> when others => -- NO_GRANTS case > >> ... > >> end case; > >> > >> Of course, if the case statement is inside a clk'event, you don't need > >> the variable. > > > >Todd, > > > >This was exactly the type of code I wrote in my first attempt to use > >VHDL to build a state machine. I did not trust the FPGA tools (too many > >bad experiences in the past) to do what I wanted using the methods I > >read in the VHDL books. The problem was that the synthesizer did not > >know that to detect state "VIDEO_GRANT" it only needed a single input. > >It would use all N state variables as the input for each condition in > >the case (state_variable == "0001" rather than just state_variable(0) == > >'1'). You are absolutely correct. I just checked FPGA Express and Design Compiler. They both do exhaustive decodes rather then figuring out that only one bit is active at a time. I never noticed this before because I generally have more trouble with my data path speed then state machine speed. In FPGA Express you can select "one-hot" or "binary" encoding for enumerated types, but again, you are giving up control to the synthesis tool, and ALL of you state machines have to be the same type. I think Dan Jones has the best approach for guaranteeing one-hot behavior and still writing portable code. ToddArticle: 12726
Ad Verschueren wrote: > > "Glenn E. Hunt" <glennee@flash.net> writes: > > One design team I know of got so frustrated with its inability to comprehend > > the hierarchical structure of a device's HDL that they recast the design > > into a top-level schematic of "black boxes" and put the HDL implementation > > code under those, a technique that can obviously be extended as deeply into > > a hierarchy as one desired. > > I think that's not much more than a 'hack'. It works, but it's not optimal. I would disagree with that assessment. Perhaps I am not familiar with VHDL enough to understand how to easily represent hierarchy without using structural VHDL. Structural VHDL is not easily read so that you are much better using schematic in terms of readability. I am much more comfortable using schematic at the top level while using VHDL for modules, although not necessarily low level modules. Most of my modules relate to funcitons and will have all of the datapath, data logic and control logic for a given interface or major operation. This seems to be a good balance between readability (VHDL becomes unwieldy with large files) and functionality (schematics become cluttered when they contain too much detail). > In MS-Word, I use outlining a lot and I like it - for writing normal texts > like reports or manuals. I used the Transputer tools, and there it did not > really help me - nothing beats a schematic to show structure. I don't know > Synplicity, but our tool allows schematics to be (re-)used in a hierarchy. This is a good idea. I use outlining when I write documents or when I code in 'C'. I will try outlining the next time I use VHDL. One nice feature of outlining is that you can preserve the high level code constructs as comments which make the lowlevel code more readable. > > Having said that, it also seems to me that what we as hardware designers are > > doing is thinking like schematic designers when we write our HDL. I'm > > starting to think this is not the best way to go about writing HDL. Rather > > than focus on tools, maybe we could gain improved clarity by changing the > > way we think about the structure or partitioning of designs. Can we devise > > a design analysis/partition/capture technique or method that highlights or > > exposes rather than obscures the relationships of HDL hierarchy? > > IMHO, I think we have got one such method. If you have the freedom in speed and density, then you can afford to write the HDL as you would a 'C' program. But I have never worked on a design where my gate count did not matter and most of my designs need some level of performance which is not trivial in the technology which I was using. > > Is the > > hybrid schematic-for-higher-levels with HDL underneath good enough? That's what I use and like. ;^) -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12727
I am wondering if anyone knows where I might find a synthesizable VHDL model for an 8B/10B encoder/decoder. I know I saw a post a few months ago asking a similar question, but I did not see if there were any replies. Any help would be appreciated. -- David C. Hoffmeister dch@eng.umd.edu University of Maryland at College ParkArticle: 12728
In article <363554C6.DDADB31C@associatedpro.com>, aps@associatedpro.com says... > I read a XILINX technote that seemed to indicate that .1uf caps were > barely adequate for decouple. What value decouple caps are generally > reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10, > 50, 100 MHz ranges. The amount of misinformation on the use of decoupling capacitors is remarkable, and even replying to this question is risking a mild flame war. However, I'm willing to engage some well-mannered discussion ... For every Xilinx chip that you mention, as well as other logic, I assert that you will be quite safe with a single, 0.1uF, surface mount ceramic capacitor per power pin. You should do your layout such that the VCC and GND planes are on adjacent layers. The closely spaced planes maintain a low impedance between VCC and GND at all frequencies of interest, and as you go down in frequency the capacitors tend to work together as one larger value capacitor with exceptionally low ESR. Also, be sure that the layout connections between the capacitor pads and the planes are direct. The ideal, from a performance standpoint, would be to have vias directly under the cap contacts. (The least desireable is to have trace stubs connecting the capacitor pads to their vias.) In some unusual cases it might be beneficial to use more capacitors. For example, a PCB containing mostly high current and fast bus buffers, or a memory board. But for a typical mix of logic, the above easy-to-follow recipe will produce excellent results. As for the capacitors, I like the 50V X7R capacitors in 1206 case size. TDK is a good source; I am sure that there are many others. -- George Pontis (Replies to geo at z9 dot com.)Article: 12729
Try searching www.isdmag.com. They have excellent eda tool summaries. >Hi everyone ! > >I am looking for some EDA tools that are running under Win 95/ Win NT PC's. > >The tools should have : > - VHDL compiler & simulator > - FPGA synthesis > - some way to check that what goes out from synthesis is what you >need > >Anyone knows some tools like that please let me know. I heard about >PeakVHDL, >but I need some other, for comparison. Price/quality is the issue here. > >Thank you, everybody. > >************************************************************ >Ovidiu Lupas >Design Engineer >TimTeh Electronics Ltd. > >e-mail : ovilup@hotmail.com >home e-mail : ovilup@mail.dnttm.ro phone : 40-56-121951 >work e-mail : lupas@timteh.dnttm.ro phone/fax : 40-56-198943 >************************************************************ >Article: 12730
CALL FOR PAPERS
EvoIASP '99
FIRST EUROPEAN WORKSHOP ON EVOLUTIONARY COMPUTATION
IN IMAGE ANALYSIS AND SIGNAL PROCESSING
GOTEBORG, 28 May, 1999
Evolutionary algorithms have been shown to be tools which can be used
effectively in the development of systems (software or hardware) for
image analysis and signal processing in complex domains of high
industrial and social relevance.
EvoIASP '99 will be the first European event specifically dedicated to
the applications of evolutionary computation (EC) to image analysis
and signal processing (IASP) and will give European and non-European
researchers in those fields, as well as people from industry, an
opportunity to present their latest research, discuss current
developments and applications, besides fostering closer future
interaction between members of the three scientific communities.
The event will be held at Chalmers University of Technology in
Goteborg, Sweden.
The workshop is sponsored by EvoNet, the Network of Excellence in
Evolutionary Computing, and is one of the activities of EvoIASP, the
EvoNet working group on Evolutionary Computation in Image Analysis and
Signal Processing. It will be held in conjunction with four other
major European events:
* EuroGP'99, the second European workshop on genetic programming,
* EvoRobot'99, the second European workshop on evolutionary robotics,
* EuroECTel'99, the first European workshop on evolutionary
telecommunications,
* EvoSCONDI'99, the first European workshop on evolutionary
computation for systems, control and drives industry,
Topics of interest include, but are not limited to:
- Applications of evolutionary computation to real-life IASP problems
- Evolvable vision and signal processing hardware
- Evolutionary pattern recognition
- Hybrid architectures for machine vision and signal processing
including evolutionary components
- Theoretical developments
- Comparisons between different evolutionary techniques and between
evolutionary and non-evolutionary techniques in IASP applications
- Financial time series analysis by means of EC techniques.
The workshop will consist of:
- An invited talk by Dana Ballard
- Oral and poster sessions with periods for discussion
- Software demos and industrial stands
Fees: Registration fees are still being finalised and will be
publicised shortly.
Registration to EvoIASP'99 will include free non-transferable
registration to EvoRobot'99, EuroGP'99, EuroECTel'99 and EvoSCONDI'99
(and vice versa).
A reduced registration rate will be available for students.
Submissions:
To submit, send your manuscript (max length: 10 A4 pages) to one of
the programme co-chairs in PostScript (preferably compressed and
uuencoded) BY EMAIL (see addresses below) not later than December 15,
1998. The papers will be peer reviewed by at least two members of the
programme committee, of whom at least one from the evolutionary
computation community and one from the image analysis or signal
processing community. Authors will be notified via email on the
results of the review by January 15, 1999.
The authors of accepted papers will have four weeks to improve their
paper on the basis of the reviewers' comments and will be asked to
send a camera ready version of their manuscripts by February 15th,
1999. The papers accepted will appear in the workshop proceedings
which will be available at the workshop.
----------------------------------------------------------------------------
Organising Committee:
* Riccardo Poli, The University of Birmingham, UK (Programme
co-chair)
e-mail: R.Poli@cs.bham.ac.uk
* Hans-Michael Voigt, GFaI - Center for Applied Computer Science,
Berlin,
Germany (Programme co-chair) e-mail:voigt@gfai.de
* Terry Fogarty, Napier University, UK (Publication chair) e-mail:
T.Fogarty@dcs.napier.ac.uk
* Stefano Cagnoni, University of Parma, Italy (Publicity chair)
e-mail: cagnoni@ce.unipr.it
* Peter Nordin, Chalmers University of Technology (Local chair)
email:
nordin@fy.chalmers.se
Programme Committee:
* Giovanni Adorni, University of Parma, Italy
* Jarmo Alander, University of Vaasa, Finland
* Dana Ballard, University of Rochester, USA
* Wolfgang Banzhaf, University of Dortmund, Germany
* Suchendra Bhandarkar, University of Georgia, USA
* Alberto Broggi, University of Pavia, Italy
* Stefano Cagnoni, University of Parma, Italy
* Ela Claridge, The University of Birmingham, UK
* Jason Daida, University of Michigan, USA
* Terry Fogarty, Napier University, UK
* David Hogg, University of Leeds, UK
* Mario Koeppen, FhG IPK, Germany
* W.B. Langdon, The University of Birmingham, UK
* Evelyne Lutton, INRIA, France
* Peter Nordin, Chalmers University of Technology, Sweden
* Riccardo Poli, The University of Birmingham, UK
* Jim Smith, University of Western England, UK
* Jacques Levy Vehel, INRIA, France
* Hans-Michael Voigt, GFaI - Center for Applied Computer Science,
Germany
Venue:
Main Aula, Goteborg University, Vasaparken, Goteborg Directions can be
found
on the Web site of the workshops.
Information on Goteborg
Accommodation:
Some prices for May 99 are still approximate. Breakfast usually
included.
* Maria Erikssons Pensionat, Chalmersgatan 27, +46 31 20 70 30,
395-595
SEK, Dorm 200SEK-250SEK, +46 31 166463, Distance 100 m
* Hotel Flora, Gronsakstorget 2, +46 31 13 86 16, Fax +46 31 13 24
08,
360-850 SEK, hotelflora.ab@swipnet.se, up to 6 beds in a few
rooms,Distance 600m
* Hotel Vanilj, Kyrkogatan 38, +46 31 7116220, Fax: +46 31 7116230,
info@vaniljhotel.entersol.se, 595-895 SEK , 4 beds 1295 SEK,
Distance
300m
* Hotel Posseidon, Storgatan 33, +49 31 10 05 50, Fax: +49 31 13 83
91,
Single 890 SEK, Double 1250, jige@algonet.se, Distance 200m
* Hotel Mornington, 800 SEK, Kungsportsavenyn 9,
mornington.hotel-gbg@wmhotels.se, +49 31 176540, Fax +49 31 711 34
39,
Distance 200m
* Hotel Excelsior, Karl Gustavsgatan 7, +46 31 17 54 35, Fax +46 31
17 54
39, email: hotel.exelisio@tripnet.se,
http://www.tripnet.se/excelsior,
625-792 SEK, Distance 150m
* Hotel Rubinen Kungsportavenyn 24, +46 31 81 08 00, Fax +46 31
167586,
reception.rubinen@scandic-hotels.se,
reservation.rubinen@scandic-hotels.se, 1295-1965 SEK, Distance 300m
Local arrangements:
In case help is needed regarding venue and/or accommodation, please
contact
Peter Nordin
email: nordin@fy.chalmers.se
Institute of Physical Resource Theory
Chalmers University of Technology
S-412 96 Goteborg, SWEDEN
Timetable:
Submission deadline: 15 December 1998
Notification of acceptance: 15 January 1999
Camera ready papers for workshop: 15 February 1999
Workshop: 28 May 1999
Workshop Web Site:
http://www.ce.unipr.it/people/cagnoni/evoiasp99.html
Contacts:
Stefano Cagnoni
email: cagnoni@ce.unipr.it
Department of Computer Engineering
University of Parma
43100 Parma ITALY
Tel: +39 0521 905731, Fax +39 0521 905723
Peter Nordin
email: nordin@fy.chalmers.se
Institute of Physical Resource Theory
Chalmers University of Technology
S-412 96 Goteborg, SWEDEN
Tel: +46 31 607213, Fax +46 31 607201
Article: 12731Hi, I am working on a home project to make a small Xilinx FPGA based hobby board! I want to make it as cheap as possible and want to configure the board directly from the ISA bus. My plan is to have a small PLD (16V8) to decode the main address of the board, and a 245 on the data bus. Then I conect the DIN to DATA(0) (after buffer) and connect all the other configuarion pins to signals from the PLD. I found an application note on xilinx'x homesite, about the similar project, but there they send the data in serial, but I wonder if anyone knows if it is possible to send the data in parallell, using the "peripheral Synchronous" mode? And in that case how do I download the bit file? Really appreciate your help, Regards, Farhad A.Article: 12732
I had good luck with an Altera design running at 50Mhz with the following: 1206 ferrite bead isolating a Vcc network with 0.1uF ceramic caps (one per power pin like George suggests), spread around a power "ring" (.050 trace of 1 oz copper) that fed the device. I felt like, if there was a real hot circuit that needed special handling, having this isolation would allow me to do something about it. I could increase the Z of the bead and increase the capacitance, as necessary. But it wasn't necessary, conducted and radiated emissions were in spec. YMMV, IMO, Caveat Emptor, etc. George Pontis wrote in message ... >In article <363554C6.DDADB31C@associatedpro.com>, aps@associatedpro.com >says... >> I read a XILINX technote that seemed to indicate that .1uf caps were >> barely adequate for decouple. What value decouple caps are generally >> reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10, >> 50, 100 MHz ranges. > >The amount of misinformation on the use of decoupling capacitors is >remarkable, and even replying to this question is risking a mild flame >war. However, I'm willing to engage some well-mannered discussion ... > >For every Xilinx chip that you mention, as well as other logic, I assert >that you will be quite safe with a single, 0.1uF, surface mount ceramic >capacitor per power pin. You should do your layout such that the VCC and >GND planes are on adjacent layers. The closely spaced planes maintain a >low impedance between VCC and GND at all frequencies of interest, and as >you go down in frequency the capacitors tend to work together as one >larger value capacitor with exceptionally low ESR. Also, be sure that the >layout connections between the capacitor pads and the planes are direct. >The ideal, from a performance standpoint, would be to have vias directly >under the cap contacts. (The least desireable is to have trace stubs >connecting the capacitor pads to their vias.) > >In some unusual cases it might be beneficial to use more capacitors. For >example, a PCB containing mostly high current and fast bus buffers, or a >memory board. But for a typical mix of logic, the above easy-to-follow >recipe will produce excellent results. > >As for the capacitors, I like the 50V X7R capacitors in 1206 case size. >TDK is a good source; I am sure that there are many others. > >-- >George Pontis > >(Replies to geo at z9 dot com.)Article: 12733
I've had excellent results by routing the power from the via THRU the cap's pad then to the device. Doing it this way uses the trace inductance to your advantage by creating a T filter. One cap per VCC pin works fine, with 0.047 to 0.1 uf per cap. As was mentioned, you should have VCC and Ground planes on adjacent layers to keep supply impedance low. In most cases, you don't need the bead this way. Ken Coffman wrote: > I had good luck with an Altera design running at 50Mhz with the following: > 1206 ferrite bead isolating a Vcc network with 0.1uF ceramic caps (one per > power pin like George suggests), spread around a power "ring" (.050 trace of > 1 oz copper) that fed the device. I felt like, if there was a real hot > circuit that needed special handling, having this isolation would allow me > to do something about it. I could increase the Z of the bead and increase > the capacitance, as necessary. But it wasn't necessary, conducted and > radiated emissions were in spec. > YMMV, IMO, Caveat Emptor, etc. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 12734
Mark Zenier wrote: > >>It's not working as a digital circuit. There's no clock provided to > >>the FPGA. Operation depends on circuit strays, and will only work > >>in a 10 degree C temperature range. > But you can't make any claims about efficiency when you have an > unanalyzable, and therefore unreliable random hack. (I'm just going > by the New Scientist article, maybe their book covers that). > > But then it would evolve in a slower, less entertaining way. > > Mark Zenier mzenier@eskimo.com mzenier@netcom.com Washington State resident I have seen two basic types of FPGA based evolvable hardware strategies (both based on the xc6200). Number one is the random method. This method produces a result that works over a small temperature range and is nearly impossible to reverse engineer. These circuits are the most life like. They die when they get too hot or too cold and nobody knows how they really work. They do things that you wouldn't think could be done with the materials at hand kind of like saying "and you got a human out of that little strand of DNA?". Yet another method involves selecting a set of primitives (like switching networks) look for http://www.genetic-programming.com/jkpubs97.html then search for 6216. -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 12735
Hi, I am currently working on using Xilinx FPGA to accelerate MPEG motion estimation algorithm. Does anyone here know some similiar is undergoing and where? Thanks a lot. ChenweiArticle: 12736
Remember the last comp.arch discussion about minimalist CPUs about six months
ago? It started, as usual, with the discussion about 1-instruction CPUs and
the like, but it ended with a discussion about the best CPU you could fit in
a small FPGA?
Well XACT just finished the first successful place&route of my new small
CPU so I should be ready to put it up on the net in the next few days. I'm
pretty sure that I'm going to release it as copylefted freeware. Before I
make this first release I thought I'd get one cycle of comments on it,
before the instruction set is cast in stone.
The original goal was to make the best possible CPU in the limited resources
available in the cheapest Xilinx FPGA. This is what I've come up with:
- Fits in Xilinx XC5202 FPGA. This is Xilinx's cheapest FPGA: DIGIKEY sells
them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin
PLCC version. It has 64 CLBs, each with four FFs and four 4-input FMAPs.
- The design is in Xilinx XACT in OrCAD schematics. I'll release the
OrCAD source, postscript printouts of the schematics and a Xilinx macro
of the CPU.
- It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part. I should
be able to get this a bit faster. It would almost certainly nearly double
in speed if I use 40 more FFs for a decode pipeline register, but I think
the extra space is more valuable for peripherals. I'll use the remaining
space for a timer, a serial port and parallel ports. The minimal computer
will be this FPGA, a byte-wide ram and rom, and an oscillator. The FPGA
loads itself from the ROM, which then also contains the boot code. I'm
hoping that it will compete with microcontrollers. The extra space in the
FPGA could be used with a huge variety of possible peripherals (PLL, LCD
interface, IDE-interface, floppy interface, printer interface, keyboard,
video, who knows what else?). I want to collect a library of these on
my ftp site.
- It is not compatible with anything. I was originally considering making
a 6502 clone, but this is smaller and better (and I didn't want to
implement decimal mode). I'll write an assembler for it, hopefully for
this first release (I need to write one to test it anyway).
- Unlike the 6502, no operations occur in sequence with memory accesses.
I.E., the ALU operation time does not detract from the memory performance.
However, I do ALU operations on writes, but this is less of a problem than
reads or address calculation.
- The CPU has the following programmable registers: 16-bit accumulator,
16-bit program counter, 16-bit stack pointer, and 5-condition flag bits
(the usual carry, overflow, negative, zero and interrupt enable).
- It can operate on 16-bit words, unsigned bytes and signed bytes.
- It has the following addressing modes: immediate, stack (stack-pointer
plus 8-bit offset), and indexed (pick one of the first four words on the
stack and add a 7-bit offset). Note that it does not have direct
addressing- you have to put the address on the stack first. I chose to
make it powerful enough to use data structures easily above the
convenience of direct addressing.
- It is by no means a RISC processor; instead it more like a classic 8-bit
CPU. Instructions take 2-9 cycles to execute, where one cycle equals one
memory access. Yes, the hard-coded schematic instruction sequencer was a
big pain.
- It has interrupts. When there's an interrupt, all of the registers are
pushed on the stack. To return from the interrupt, pop all of the registers
off of the stack using the 'pop' instruction. 'pop' is also used for
subroutine returns.
- Unconditional and conditional jumps take a 16-bit destination address. I
would have done the usual pc-relative branches, but this saves space
instruction sequencer space.
- Instructions are either 2 or 4 bytes and are encoded as follows:
1 m w a a a a r r d d d d d d d indexed
0 m w a a a a 1 d d d d d d d d stack
0 1 w a a a a 0 i i i i i i i i immediate
0 0 1 c c c c 0 - - - - - - - - jump on condition (jcc)
0 0 0 1 1 1 1 0 d d d d d d d d jump to subroutine indirect (jsr)
0 0 0 1 1 1 0 0 d d d d d d d d jump indirect (address on stack)
0 0 0 1 1 0 1 0 - - - - - - - - jump to subroutine direct (jsr)
0 0 0 1 1 0 0 0 - - - - - - - - jump direct (jmp)
0 0 0 1 0 1 1 0 - - - - - a f p push registers (psh)
0 0 0 1 0 1 0 0 - - - - - a f p pop registers (pop)
0 0 0 1 0 0 1 0 v v v v v v v 0 software interrupt (brk)
0 0 0 1 0 0 0 0 - - - - - - - - extra op-code space
0 0 0 0 - - - - - - - - - - - - extra op-code space
Where: m=1: register/memory instructions
m=0: read-modify-write instructions
cccc: condition code
rr: base address no. (first four stack words)
ddddddd: 7-bit offset
dddddddd: 8-bit offset
iiiiiiii: 8-bit immediate value. 16-bit immediate values appear in the
following word.
a f p: accumulator, flags, program counter: i.e., which regs to push/pop
vvvvvvv: software interrupt vector no.
aaaa: op-code
----: unused
read-modify-write op codes:
0000 sta store accumulator word
stab store accumulator byte
0001 sts store stack pointer
0010 lsl logical shift left word
lslb logical shift left byte
0011 rol rotate left word
rolb rotate left byte
0100 lsr logical shift right word
lsrb logical shift right byte
0101 ror rotate right word
rorb rotate right byte
0110 asr arithmetic shift right word
asrb arithmetic shift right byte
0111 com 1's complement word
comb 1's complement byte
1000 neg negate word
negb negate byte
1001 cng carry-negate
cngb carry-negate byte
1010 dec decrement word
decb decrement byte
1011 csb subtract carry from word
csbb subtract carry from byte
1100 inc increment word
incb increment byte
1101 cad add carry to word
cadb add carry to byte
1110 clr clear word
clrb clear byte
1111 - extra rmw code
register-memory (and register-immediate) op codes:
0000 nop
0001 tst test word
tstbx test byte sign extended
0010 or or word
orb or byte
0011 xor xor word
xorbx xor byte sign extended
0100 bit bit-test word
bitb bit-test byte
0101 and and word
andbx and byte sign exteneded
0110 add add word
addb add byte
0111 adc add with carry word
addbx add byte sign extend
1000 cmp compare word
cmpb compare byte
1001 cwc compare word with carry
cmpbx compare byte sign extend
1010 sub subtract word
subb subtract byte
1011 sbc subtract word with carry
subbx subtract byte sign extend
1100 lda load word
ldab load byte
1101 lda load word
ldabx load byte sign extend
1110 lds load stack pointer
ldsb load stack pointer from byte
1111 adds add word to stack pointer
addsbx add sign extended byte to stack pointer
- loads, stores and add to stack pointer do not affect the flags, everything
else does (except that logical instructions do not affect carry or
overflow).
- I haven't decided where the reset or interrupt vectors or addresses are
going to be yet.
- It uses a two-phase clock system for controlling the internal tri-state
ALU B-side bus. Basically the oscillator needs to be double the clock
frequency.
Anyway, that's it. Let me know what you think.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 12737
I read a XILINX technote that seemed to indicate that .1uf caps were
barely adequate for decouple. What value decouple caps are generally
reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10,
50, 100 MHz ranges.
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 12738I'm after a board for the new Virtex chip from Xilinx. What I would like to do is get a PCI Board which I can plug the chip into, and start designing with the Foundation series software. Can anyone tell me if there is such a beast? And if so how much. Actually if the cost is to high, I'm toying with the idea of designing my own board for the task. I'd be really interested to hear from anyone else out there who is contemplating tackling the the same task. Cheers. - --------------------------------------------------------------------------------------------- David Braendler http://gene.bsee.swin.edu.au/daveb/ Centre for Intelligent Systems Swinburne University of Technology --------------------------------------------------------------------------------------------Article: 12739
You can find a tutorial page that discusses hardware architectures for coding and decoding Reed Solomon codes at: http://www.4i2i.com/reed_solomon_codes.htm Hope this is of interest. ----- Iain E G Richardson, Technical Director 4i2i Communications Ltd Doig Scott Building, Craibstone Estate, Bucksburn, Aberdeen AB21 9YA, UK Email richardson@4i2i.com.REMOVE, Web http://www.4i2i.com/ Tel +44 1224 712844, Fax +44 1224 714413Article: 12740
hi joe,
read through part of it - how about .pdf or something - it's not easy for us to
read postscript here and we don't have the xilinx tools up and running. and for
many of our applications, i would be interesting in evaluating it in a different
architecture.
thanks,
rk
--------------------------------
Joseph H Allen wrote:
> Remember the last comp.arch discussion about minimalist CPUs about six months
> ago? It started, as usual, with the discussion about 1-instruction CPUs and
> the like, but it ended with a discussion about the best CPU you could fit in
> a small FPGA?
>
> Well XACT just finished the first successful place&route of my new small
> CPU so I should be ready to put it up on the net in the next few days. I'm
> pretty sure that I'm going to release it as copylefted freeware. Before I
> make this first release I thought I'd get one cycle of comments on it,
> before the instruction set is cast in stone.
>
> The original goal was to make the best possible CPU in the limited resources
> available in the cheapest Xilinx FPGA. This is what I've come up with:
>
> - Fits in Xilinx XC5202 FPGA. This is Xilinx's cheapest FPGA: DIGIKEY sells
> them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin
> PLCC version. It has 64 CLBs, each with four FFs and four 4-input FMAPs.
>
> - The design is in Xilinx XACT in OrCAD schematics. I'll release the
> OrCAD source, postscript printouts of the schematics and a Xilinx macro
> of the CPU.
>
> - It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part. I should
> be able to get this a bit faster. It would almost certainly nearly double
> in speed if I use 40 more FFs for a decode pipeline register, but I think
> the extra space is more valuable for peripherals. I'll use the remaining
> space for a timer, a serial port and parallel ports. The minimal computer
> will be this FPGA, a byte-wide ram and rom, and an oscillator. The FPGA
> loads itself from the ROM, which then also contains the boot code. I'm
> hoping that it will compete with microcontrollers. The extra space in the
> FPGA could be used with a huge variety of possible peripherals (PLL, LCD
> interface, IDE-interface, floppy interface, printer interface, keyboard,
> video, who knows what else?). I want to collect a library of these on
> my ftp site.
>
> - It is not compatible with anything. I was originally considering making
> a 6502 clone, but this is smaller and better (and I didn't want to
> implement decimal mode). I'll write an assembler for it, hopefully for
> this first release (I need to write one to test it anyway).
>
> - Unlike the 6502, no operations occur in sequence with memory accesses.
> I.E., the ALU operation time does not detract from the memory performance.
> However, I do ALU operations on writes, but this is less of a problem than
> reads or address calculation.
>
> - The CPU has the following programmable registers: 16-bit accumulator,
> 16-bit program counter, 16-bit stack pointer, and 5-condition flag bits
> (the usual carry, overflow, negative, zero and interrupt enable).
>
> - It can operate on 16-bit words, unsigned bytes and signed bytes.
>
> - It has the following addressing modes: immediate, stack (stack-pointer
> plus 8-bit offset), and indexed (pick one of the first four words on the
> stack and add a 7-bit offset). Note that it does not have direct
> addressing- you have to put the address on the stack first. I chose to
> make it powerful enough to use data structures easily above the
> convenience of direct addressing.
>
> - It is by no means a RISC processor; instead it more like a classic 8-bit
> CPU. Instructions take 2-9 cycles to execute, where one cycle equals one
> memory access. Yes, the hard-coded schematic instruction sequencer was a
> big pain.
>
> - It has interrupts. When there's an interrupt, all of the registers are
> pushed on the stack. To return from the interrupt, pop all of the registers
> off of the stack using the 'pop' instruction. 'pop' is also used for
> subroutine returns.
>
> - Unconditional and conditional jumps take a 16-bit destination address. I
> would have done the usual pc-relative branches, but this saves space
> instruction sequencer space.
>
> - Instructions are either 2 or 4 bytes and are encoded as follows:
>
> 1 m w a a a a r r d d d d d d d indexed
> 0 m w a a a a 1 d d d d d d d d stack
> 0 1 w a a a a 0 i i i i i i i i immediate
> 0 0 1 c c c c 0 - - - - - - - - jump on condition (jcc)
> 0 0 0 1 1 1 1 0 d d d d d d d d jump to subroutine indirect (jsr)
> 0 0 0 1 1 1 0 0 d d d d d d d d jump indirect (address on stack)
> 0 0 0 1 1 0 1 0 - - - - - - - - jump to subroutine direct (jsr)
> 0 0 0 1 1 0 0 0 - - - - - - - - jump direct (jmp)
> 0 0 0 1 0 1 1 0 - - - - - a f p push registers (psh)
> 0 0 0 1 0 1 0 0 - - - - - a f p pop registers (pop)
> 0 0 0 1 0 0 1 0 v v v v v v v 0 software interrupt (brk)
> 0 0 0 1 0 0 0 0 - - - - - - - - extra op-code space
> 0 0 0 0 - - - - - - - - - - - - extra op-code space
>
> Where: m=1: register/memory instructions
> m=0: read-modify-write instructions
> cccc: condition code
> rr: base address no. (first four stack words)
> ddddddd: 7-bit offset
> dddddddd: 8-bit offset
> iiiiiiii: 8-bit immediate value. 16-bit immediate values appear in the
> following word.
> a f p: accumulator, flags, program counter: i.e., which regs to push/pop
> vvvvvvv: software interrupt vector no.
> aaaa: op-code
> ----: unused
>
> read-modify-write op codes:
> 0000 sta store accumulator word
> stab store accumulator byte
> 0001 sts store stack pointer
> 0010 lsl logical shift left word
> lslb logical shift left byte
> 0011 rol rotate left word
> rolb rotate left byte
> 0100 lsr logical shift right word
> lsrb logical shift right byte
> 0101 ror rotate right word
> rorb rotate right byte
> 0110 asr arithmetic shift right word
> asrb arithmetic shift right byte
> 0111 com 1's complement word
> comb 1's complement byte
> 1000 neg negate word
> negb negate byte
> 1001 cng carry-negate
> cngb carry-negate byte
> 1010 dec decrement word
> decb decrement byte
> 1011 csb subtract carry from word
> csbb subtract carry from byte
> 1100 inc increment word
> incb increment byte
> 1101 cad add carry to word
> cadb add carry to byte
> 1110 clr clear word
> clrb clear byte
> 1111 - extra rmw code
>
> register-memory (and register-immediate) op codes:
> 0000 nop
> 0001 tst test word
> tstbx test byte sign extended
> 0010 or or word
> orb or byte
> 0011 xor xor word
> xorbx xor byte sign extended
> 0100 bit bit-test word
> bitb bit-test byte
> 0101 and and word
> andbx and byte sign exteneded
> 0110 add add word
> addb add byte
> 0111 adc add with carry word
> addbx add byte sign extend
> 1000 cmp compare word
> cmpb compare byte
> 1001 cwc compare word with carry
> cmpbx compare byte sign extend
> 1010 sub subtract word
> subb subtract byte
> 1011 sbc subtract word with carry
> subbx subtract byte sign extend
> 1100 lda load word
> ldab load byte
> 1101 lda load word
> ldabx load byte sign extend
> 1110 lds load stack pointer
> ldsb load stack pointer from byte
> 1111 adds add word to stack pointer
> addsbx add sign extended byte to stack pointer
>
> - loads, stores and add to stack pointer do not affect the flags, everything
> else does (except that logical instructions do not affect carry or
> overflow).
>
> - I haven't decided where the reset or interrupt vectors or addresses are
> going to be yet.
>
> - It uses a two-phase clock system for controlling the internal tri-state
> ALU B-side bus. Basically the oscillator needs to be double the clock
> frequency.
>
> Anyway, that's it. Let me know what you think.
> --
> /* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 12741
Steve Bird wrote:
>
> Your ideas about a mixed schematic/HDL environment hit, what I feel is,
> a very important point. HDL's are very effective for expressing intent
> in terms of isolated bubbles of functionality. They are poor in
> expressing the connectivity between these bubbles. Whilst schematics are
> a way forward the current pin based mechanism does not scale well with
> size. You cannot easily express association between signals and they
> rarely show any form of data flow. Also thought of having to connect up
> 300+ I/O signals at the top level makes me shudder, all that routing,
> moving, parallel lines to follow...
Not trying to put a commercial ad here, but from your description, this
kind of product reminds me very much of Renoir (HDL graphical entry tool
from Mentor). You can draw your top design as a schematic, and you can
edit each sub-block in VHDL if you want to (or with a state machine
editor).
For each level of the hierarchy, you choose the view you prefer:
schematics, VHDL text, state machine, and more.
I think that's the future of VHDL entry.
However, the only issue to take care of is compatibility: how do I
guarantee that if I send my files to another VHDL user, he will see the
same thing? Or at leat that he sees something that is easy enough to
understand. Not everyone is expected to own the exact same tool. And we
still have to work all together.
Alain.
--
-----------------------------------------------------------------------
Alain RAYNAUD META SYSTEMS
R&D Logic Design Team LP 853
3 Avenue du Canada - Batiment Sigma
Tel: (33) 01 64 86 61 69 91975 Courtaboeuf Cedex - FRANCE
E-Mail: Alain_Raynaud@mentorg.com Fax: (33) 01 64 86 61 61
-----------------------------------------------------------------------
Article: 12742On Tue, 27 Oct 1998 00:06:14 -0500, Richard Schwarz <aps@associatedpro.com> wrote: >I read a XILINX technote that seemed to indicate that .1uf caps were >barely adequate for decouple. What value decouple caps are generally >reccomended with E, XL, XLA, and Spartan FPGAs for circuits in the 10, >50, 100 MHz ranges. this is one of those questions where 5 people will give you 6 answers. here's a few more: 1) 100n caps can be a problem, because their usable frequency range (reactance less than ~ 1 ohm, assuming 5 nH parasitic inductance for an MLC cap on a PCB) is low (less than 10MHz). as a rule of thumb, use 47n/100n for 10MHz or less, 22n for 7-40MHz, 10n for 10-50MHz, 500pF for 100MHz, 100pF for 200MHz. 2) obviously, a lower value cap can store less charge, and so may not be able to deliver your instantaneous power requirements. in other words, you need more of the lower-valued caps. you'll need to work out what your instantaneous power requirements are, and to come up with some compromise on the number of caps and their values. 3) use pwr/gnd planes if possible, put caps on the same side as the device, use good (low inductance) caps, ie. multi-layer ceramics, etc. 4) don't be tempted to put vias under the cap's contacts. this could lead to assembly problems. 5) be careful when paralleling up different value caps, in an attempt to get a wider frequency response for the pair. the pair will have a high reactance at intermediate frequencies (a parallel resonant peak), which may cause problems. this is less pronounced as the two values converge (a 10n/22n combination, for instance, gives a range of approx. 5 - 70MHz, with only a small peak at mid-ranges). 6) check the datasheet for the cap - try to match the self-resonant frequency to your clock rate or expected noise frequency (or see (1) above for an approximation). you may also find that the manufacturer specifies how much charge you can get off the cap per unit time, which could simplify your calculations. 7) some manufacturers do low-inductance packages - in these, you connect up the long side of the SMD package, rather than the short side. this'll allow you to use larger value caps. 8) a good layout is as follows (irrespective of whether you've got pwr/gnd planes or not): power: try to put an additional pwr plane, even if only partial, on the topside under the device. put in one or two vias under the device (*not* near the caps). route a thick track from the device power pin directly to the cap (preferably 5mm or less). gnd: route a thick track from the cap to the corresponding device gnd pin. again, try to keep it to 5mm or less. you can put a via in this track. 9) if you can't be bothered to do the calculations, here's another (possibly dangerous) rule-of-thumb. do a good layout with maybe 4 or 5 caps connected with short topside tracks to pwr/gnd pin pairs on the device, with one more cap connected to the planes (with vias) a bit further away. put a 100n cap in this location, and select the others according to your clock frequency, down to a minimum of 10n. if your device is clocking at 70MHz or more, parallel up two caps in each of the 4 or 5 locations, and experiment. evanArticle: 12743
I think this is excellent! >- Fits in Xilinx XC5202 FPGA. This is Xilinx's cheapest FPGA: DIGIKEY sells > them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin > PLCC version. It has 64 CLBs, each with four FFs and four 4-input FMAPs. Not to mention the very small area in an *ASIC*. >- The design is in Xilinx XACT in OrCAD schematics. I'll release the > OrCAD source, postscript printouts of the schematics and a Xilinx macro > of the CPU. Nice one! >- It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part. I should > be able to get this a bit faster. It would almost certainly nearly double > in speed if I use 40 more FFs for a decode pipeline register, but I think > the extra space is more valuable for peripherals. I think you are right. This is fast enough for most apps like this. >- It is not compatible with anything. I was originally considering making > a 6502 clone, but this is smaller and better (and I didn't want to > implement decimal mode). I'll write an assembler for it, hopefully for > this first release (I need to write one to test it anyway). Make sure it runs in the DOS box of NT4 :) And returns the various errorlevels, so it can run out of a makefile. >- It has the following addressing modes: immediate, stack (stack-pointer > plus 8-bit offset), and indexed (pick one of the first four words on the > stack and add a 7-bit offset). Note that it does not have direct > addressing- you have to put the address on the stack first. I chose to > make it powerful enough to use data structures easily above the > convenience of direct addressing. Interesting. This however seems to favour HLL support, whereas such a CPU would normally be programmed in asm. Being able to do ld hl, (543dh) is rather useful. >- It has interrupts. When there's an interrupt, all of the registers are > pushed on the stack. To return from the interrupt, pop all of the registers > off of the stack using the 'pop' instruction. 'pop' is also used for > subroutine returns. Nice. How fast is this pushall/popall? >- I haven't decided where the reset or interrupt vectors or addresses are > going to be yet. Will you be doing vectored ints, where the device can supply half the vector? I think that would be overkill, since it needs complex peripherals and it is far easier to simply encode each of say 8 /IRQ sources into eight equally spaced addresses. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 12744
Please include your code so we may better help you! Tom Tessier Andrea wrote: > > I have this problem when trying to compile vhdl source with Orcad Express > 7.01: > > - NO POSSIBLE REGISTER IMPLEMENTATION with clock 'clk' > > What's mean? > I need to write code in vhdl for a memory (50*24; for a specific > application) which is synthetizable: i tried several ways ... > I hope you can help me suggesting the code that i can use. I'm a student and > this is my first vhdl program! > Thank you > > <<<AN e-mail: andnas@tin.it>>> -- +------------------------ ---------------------- ----------------------+ : t2design : : 249 Lois Drive : : Louisville, CO 80027 : +------------------------ ---------------------- ----------------------+ : tomt@hdl-design.com * (303)665-6402 * Fax: (303)665-6431 : +------------------------ ---------------------- ----------------------+Article: 12745
ems@riverside-machines.com.NOSPAM wrote: <snip> >gnd: >route a thick track from the cap to the corresponding device gnd pin. >again, try to keep it to 5mm or less. you can put a via in this track. The 'thick track' may not be necessary. Remember, you want to minimize the inductance between the capacitor lead and the FPGA power pin. That lowers ESR (External Series Reactance). I've found that a lot of people want to use thick traces to reduce inductance, but it really doesn't do that. The major cause of inductance between the capacitor and IC power pin is loop area of the signal trace.Article: 12746
Could you compile this for my Design Your Own Processor(tm) board?
I am using the XC4005 or XC4010. I can send you a .UCF for pin
placement.
I would love to distribute this as part of out tools. (object code
only or ?)
Simon - see my sig to find out what we are up to.
===========================================================
jhallen@world.std.com (Joseph H Allen) wrote:
>Remember the last comp.arch discussion about minimalist CPUs about six months
>ago? It started, as usual, with the discussion about 1-instruction CPUs and
>the like, but it ended with a discussion about the best CPU you could fit in
>a small FPGA?
>
>Well XACT just finished the first successful place&route of my new small
>CPU so I should be ready to put it up on the net in the next few days. I'm
>pretty sure that I'm going to release it as copylefted freeware. Before I
>make this first release I thought I'd get one cycle of comments on it,
>before the instruction set is cast in stone.
>
>The original goal was to make the best possible CPU in the limited resources
>available in the cheapest Xilinx FPGA. This is what I've come up with:
>
>- Fits in Xilinx XC5202 FPGA. This is Xilinx's cheapest FPGA: DIGIKEY sells
> them for $10.15 in single quantities or $7.40 in hundreds for the 84-pin
> PLCC version. It has 64 CLBs, each with four FFs and four 4-input FMAPs.
>
>- The design is in Xilinx XACT in OrCAD schematics. I'll release the
> OrCAD source, postscript printouts of the schematics and a Xilinx macro
> of the CPU.
>
>- It uses 143 FFs and 192 FMAPs and runs at 9MHz in the -5 part. I should
> be able to get this a bit faster. It would almost certainly nearly double
> in speed if I use 40 more FFs for a decode pipeline register, but I think
> the extra space is more valuable for peripherals. I'll use the remaining
> space for a timer, a serial port and parallel ports. The minimal computer
> will be this FPGA, a byte-wide ram and rom, and an oscillator. The FPGA
> loads itself from the ROM, which then also contains the boot code. I'm
> hoping that it will compete with microcontrollers. The extra space in the
> FPGA could be used with a huge variety of possible peripherals (PLL, LCD
> interface, IDE-interface, floppy interface, printer interface, keyboard,
> video, who knows what else?). I want to collect a library of these on
> my ftp site.
>
>- It is not compatible with anything. I was originally considering making
> a 6502 clone, but this is smaller and better (and I didn't want to
> implement decimal mode). I'll write an assembler for it, hopefully for
> this first release (I need to write one to test it anyway).
>
>- Unlike the 6502, no operations occur in sequence with memory accesses.
> I.E., the ALU operation time does not detract from the memory performance.
> However, I do ALU operations on writes, but this is less of a problem than
> reads or address calculation.
>
>- The CPU has the following programmable registers: 16-bit accumulator,
> 16-bit program counter, 16-bit stack pointer, and 5-condition flag bits
> (the usual carry, overflow, negative, zero and interrupt enable).
>
>- It can operate on 16-bit words, unsigned bytes and signed bytes.
>
>- It has the following addressing modes: immediate, stack (stack-pointer
> plus 8-bit offset), and indexed (pick one of the first four words on the
> stack and add a 7-bit offset). Note that it does not have direct
> addressing- you have to put the address on the stack first. I chose to
> make it powerful enough to use data structures easily above the
> convenience of direct addressing.
>
>- It is by no means a RISC processor; instead it more like a classic 8-bit
> CPU. Instructions take 2-9 cycles to execute, where one cycle equals one
> memory access. Yes, the hard-coded schematic instruction sequencer was a
> big pain.
>
>- It has interrupts. When there's an interrupt, all of the registers are
> pushed on the stack. To return from the interrupt, pop all of the registers
> off of the stack using the 'pop' instruction. 'pop' is also used for
> subroutine returns.
>
>- Unconditional and conditional jumps take a 16-bit destination address. I
> would have done the usual pc-relative branches, but this saves space
> instruction sequencer space.
>
>- Instructions are either 2 or 4 bytes and are encoded as follows:
>
>1 m w a a a a r r d d d d d d d indexed
>0 m w a a a a 1 d d d d d d d d stack
>0 1 w a a a a 0 i i i i i i i i immediate
>0 0 1 c c c c 0 - - - - - - - - jump on condition (jcc)
>0 0 0 1 1 1 1 0 d d d d d d d d jump to subroutine indirect (jsr)
>0 0 0 1 1 1 0 0 d d d d d d d d jump indirect (address on stack)
>0 0 0 1 1 0 1 0 - - - - - - - - jump to subroutine direct (jsr)
>0 0 0 1 1 0 0 0 - - - - - - - - jump direct (jmp)
>0 0 0 1 0 1 1 0 - - - - - a f p push registers (psh)
>0 0 0 1 0 1 0 0 - - - - - a f p pop registers (pop)
>0 0 0 1 0 0 1 0 v v v v v v v 0 software interrupt (brk)
>0 0 0 1 0 0 0 0 - - - - - - - - extra op-code space
>0 0 0 0 - - - - - - - - - - - - extra op-code space
>
>Where: m=1: register/memory instructions
> m=0: read-modify-write instructions
> cccc: condition code
> rr: base address no. (first four stack words)
> ddddddd: 7-bit offset
> dddddddd: 8-bit offset
> iiiiiiii: 8-bit immediate value. 16-bit immediate values appear in the
> following word.
> a f p: accumulator, flags, program counter: i.e., which regs to push/pop
> vvvvvvv: software interrupt vector no.
> aaaa: op-code
> ----: unused
>
>read-modify-write op codes:
>0000 sta store accumulator word
> stab store accumulator byte
>0001 sts store stack pointer
>0010 lsl logical shift left word
> lslb logical shift left byte
>0011 rol rotate left word
> rolb rotate left byte
>0100 lsr logical shift right word
> lsrb logical shift right byte
>0101 ror rotate right word
> rorb rotate right byte
>0110 asr arithmetic shift right word
> asrb arithmetic shift right byte
>0111 com 1's complement word
> comb 1's complement byte
>1000 neg negate word
> negb negate byte
>1001 cng carry-negate
> cngb carry-negate byte
>1010 dec decrement word
> decb decrement byte
>1011 csb subtract carry from word
> csbb subtract carry from byte
>1100 inc increment word
> incb increment byte
>1101 cad add carry to word
> cadb add carry to byte
>1110 clr clear word
> clrb clear byte
>1111 - extra rmw code
>
>register-memory (and register-immediate) op codes:
>0000 nop
>0001 tst test word
> tstbx test byte sign extended
>0010 or or word
> orb or byte
>0011 xor xor word
> xorbx xor byte sign extended
>0100 bit bit-test word
> bitb bit-test byte
>0101 and and word
> andbx and byte sign exteneded
>0110 add add word
> addb add byte
>0111 adc add with carry word
> addbx add byte sign extend
>1000 cmp compare word
> cmpb compare byte
>1001 cwc compare word with carry
> cmpbx compare byte sign extend
>1010 sub subtract word
> subb subtract byte
>1011 sbc subtract word with carry
> subbx subtract byte sign extend
>1100 lda load word
> ldab load byte
>1101 lda load word
> ldabx load byte sign extend
>1110 lds load stack pointer
> ldsb load stack pointer from byte
>1111 adds add word to stack pointer
> addsbx add sign extended byte to stack pointer
>
>- loads, stores and add to stack pointer do not affect the flags, everything
> else does (except that logical instructions do not affect carry or
> overflow).
>
>- I haven't decided where the reset or interrupt vectors or addresses are
> going to be yet.
>
>- It uses a two-phase clock system for controlling the internal tri-state
> ALU B-side bus. Basically the oscillator needs to be double the clock
> frequency.
>
>Anyway, that's it. Let me know what you think.
>--
>/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
>int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
>+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
>]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htm
Article: 12747It is nothing like what you asked for but check out my sig. It might be a tool you could use or modify. I could do a custom for you at a reasonable price. Let me know by e-mail. Simon ================================================ David Braendler <dbraendler@swin.edu.au> wrote: >I'm after a board for the new Virtex chip from Xilinx. What I would like >to do is get a PCI Board which I can plug the chip into, and start >designing with the Foundation series software. > >Can anyone tell me if there is such a beast? And if so how much. > >Actually if the cost is to high, I'm toying with the idea of designing >my own board for the task. I'd be really interested to hear from anyone >else out there who is contemplating tackling the the same task. > >Cheers. > >- >--------------------------------------------------------------------------------------------- > >David Braendler http://gene.bsee.swin.edu.au/daveb/ >Centre for Intelligent Systems >Swinburne University of Technology >-------------------------------------------------------------------------------------------- > > > Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12748
This is a multi-part message in MIME format. --------------53D1942EC77E12A3AE07EB5E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit One other thing to look at is the number of through hole vias used to attach the decoupling capacitor to the power layers of the PCB and also the trace lengths. If you use multiple vias (I typically use three for both ground and power) then the inductance of each via is placed in parallel with the inductance of the other vias. The end result yields a reduction in the total inductance between the capacitor pad and the power or ground plane. Three equal inductors of value 'L' placed in parallel yield a total inductance 'L/3'. Reducing the inductance helps shift the resonant frequency of the decoupling network to higher frequencies. Inductors work to resist changes in current and the main function of the decoupling capacitor is to quickly supply current bursts to provide for the switching going on inside the IC. The two areas that the engineer can typically control are the trace lengths and the number of vias. The engineer can not control the lead inductance and the bond wire inductance of the IC. Notice here that I am talking about decoupling, and I am not talking about power filtering. In the case where you need to filter out the noise from other parts of the board, I would use a ferrite bead and possibly in extreme cases an isolated power island. But, I almost never attempt to use an isolated ground. I have found that splitting the ground is just asking for problems. My typical layout has three traces coming from each capacitor pad. One trace from the end and one trace from each side of each pad. These traces are to vias that are placed as close to the capacitor pad as the design rules will allow for the board shop I am using. I also use as wide of a trace as possible. For a 1206 pad pattern I typically use a 50 to 75 mil trace. If you can not do this on both power and ground I recommend at least doing it on ground. Ground inductance is the first thing you look at when you have ground noise or EMI problems. As far as capacitor values go you can either try and calculate the over all frequency response of your decoupling network and adjust your capacitors for resonance at your operating frequency or you can just approximate your values. As a GENERAL (notice I stressed GENERAL) rule of thumb the higher the frequency the lower your total "LOCAL" capacitance needs to be for peek decoupling. This gets real hard to deal with because you need a certain amount of capacitance to be able to supply the needed current. As you get to higher and higher frequencies you start playing games with using large bulk capacitors at the power supply (or connector) such as 10uf tantalum capacitors and medium size caps. (~0.1 uF) in the general area of the IC in question. This provides decoupling to the power planes in the area of the IC. Finally, something like 0.01 down to 0.0047 could be attached as close to the power pins as possible. This all depends on how sensitive the IC in question is to noise on the power supply and also, the EMI/EMC requirements of the finished board. Of course the biggest dependency of all is how much time you actually have to analyze the issue. If you are being pounded on to get boards done then you could just slap down a bunch of 1206 pad patterns and figure out the values in the lab.(not recommended) If the issue of noise reduction and EMI/EMC requirements interests you, try book that I have and like by Henry W. Ott called "Noise Reduction Techniques in Electronic Systems" second edition. Its ISBN number is 0-471-85068-3. Also if your company is big enough to bring in guest speakers I highly recommend Henry Ott I was very impressed by his lecture. Regards, Philip Buchholz Ray Andraka wrote: > > I've had excellent results by routing the power from the via THRU the cap's pad > then to the device. Doing it this way uses the trace inductance to your > advantage by creating a T filter. One cap per VCC pin works fine, with 0.047 to > 0.1 uf per cap. As was mentioned, you should have VCC and Ground planes on > adjacent layers to keep supply impedance low. In most cases, you don't need the > bead this way. > > Ken Coffman wrote: > > > I had good luck with an Altera design running at 50Mhz with the following: > > 1206 ferrite bead isolating a Vcc network with 0.1uF ceramic caps (one per > > power pin like George suggests), spread around a power "ring" (.050 trace of > > 1 oz copper) that fed the device. I felt like, if there was a real hot > > circuit that needed special handling, having this isolation would allow me > > to do something about it. I could increase the Z of the bead and increase > > the capacitance, as necessary. But it wasn't necessary, conducted and > > radiated emissions were in spec. > > YMMV, IMO, Caveat Emptor, etc. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka --------------53D1942EC77E12A3AE07EB5E Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Philip Buchholz Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Philip Buchholz n: Buchholz;Philip org: ODS Networks, Inc. adr: 1001 East Arapaho Rd;;;Richardson;TX;75081-2327;USA email;internet: philipb@ods.com title: Electrical Design Engineer tel;work: (972)234-6400 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------53D1942EC77E12A3AE07EB5E--Article: 12749
A guillotine for the poor PC who probably hates having this dyna-stuff on him, or for the Xilinx guy ? As for Dynatext itself, even when it runs, it don't work. Jan Martin Wagenaar beerput@tip.nl Ray Andraka wrote: > > How about a guilotine? Nothing quite like cluttering the machine up with a > bunch of non-standard documentation readers! > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka
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