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
> > I think antifuses aren't visible optically since a programmed > >conductive antifuse differs from a non-conductive one only by a small > >diffusion surface. That might be the advantage of antifuse FPGAs over > >ASIC ICs. > I would bet you could do something like a CAT or PET scan - NMR or something like that. Maybe using techniques like xray crystallography. For $350,000,000 I could just about buy Actel! -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 12826
Ok, here it is- complete except for debugging. The OrCAD .sch files and postscript versions of them are on my ftp site. I'm still writing an assembler, and the CPU won't be debugged until that's finished. The design is close enough to its final form that I'm happy to show it now. The bad news is that it just doesn't fit in a 5202, instead it uses about 1/2 of a 5204. I'm working on it :-) Trailing Edge 16 FPGA CPU - Sources located at ftp://ftp.worcester.com/pub/joe/te16.zip - Fits in a Xilinx 5204. *Almost* fits in a 5202, I'm working on it. - *.sch, OrCAD schematics. - *.ps, Postscript version of schematics. - te8.bin: Binary bitstream to load into prom. Not checked. - te8.rpt: Pin assignment report. Other te8.* are reports from Xilinx XACT. - Licensing: The sources are licensed under the Gnu-copyleft (see the file copying). This means that you can use or sell for free, but any modifications must also be placed under the Gnu-copyleft and distributed for free. Registers: MSB LSB 15 . . . 5 4 3 2 1 0 +-------------------------------+ | | Accumulator +-------------------------------+ | 0| Stack pointer +-------------------------------+ | 0| Program counter +---------------------+---------+ |N Z I V C| Condition flags +---------+ N = negative, Z = zero, I = interrupt enable, V = overflow, C = carry C = 1 for carry after an add, 0 for no carry after an add C = 0 for borrow after a subtract, 1 for no borrow after subtract V = overflow: exclusive-or of carry going into and comming out of bit 15. - Stack pointer and program counter are always even (they only point to words). - The stack builds downwards (SP is predecremented for PSH, postincremented for POP). The stack pointer points to the first word on the stack. The first free word is at SP-2. Memory format: +------------------+ | byte 0 LSB | \ +------------------+ word 0 | byte 1 MSB | / +------------------+ | byte 2 LSB | \ +------------------+ word 2 | byte 3 MSB | / +------------------+ | | . . . . . . | | +------------------+ | byte 65534 LSB | \ +------------------+ word 65534 | byte 65545 MSB | / +------------------+ - All words must be aligned on even address boundaries. - The least significant byte within each word is at the lower address (except 16-bit immediate values and direct jump addresses, see below). - Special addresses: FC00 - Reset entry point: PC is initialized to this value on reset FD00 - BRK instruction jumps to this address FE00 - IRQ instruction jumps to this address Instruction coding: - Instructions are either 2 or 4 bytes. - Instructions must be begin on even addresses only. 0 1 2 3 --- --- --- --- 1mwaaaar rddddddd indexed 0mwaaaa1 dddddddd stack 011aaaa0 llllllll hhhhhhhh -------- immediate word 010aaaa0 iiiiiiii immediate byte 001cccc0 lllllll0 hhhhhhhh -------- jump on condition (jcc) 00011110 dddddddd jump to subroutine indirect (jsr) 00011100 dddddddd jump indirect (address on stack) 00011010 lllllll0 hhhhhhhh -------- jump to subroutine direct (jsr) 00011000 lllllll0 hhhhhhhh -------- jump direct (jmp) 00010110 -----fpa push registers (psh) 00010100 -----fpa pop registers (pop) 00010010 -------- software interrupt (brk) 00010000 -------- extra op-code space 0000---0 -------- extra op-code space Where: m=1: register-memory instructions m=0: read-modify-write instructions w=1: word operand w=0: byte operand cccc: condition code rr: stack register no. (first four stack words) ddddddd: 7-bit unsigned offset dddddddd: 8-bit unsigned offset iiiiiiii: 8-bit immediate value llllllll: Low byte of 16-bit immediate value of direct jump address hhhhhhhh: High byte of 16-bit immediate value or direct jump address a f p: accumulator, flags, program counter: i.e., which regs to push/pop ----: unused aaaa: read-modidy-write or register-memory op-code (see below) read-modify-write op-codes: 0000 sta store accumulator word stab store accumulator byte 0001 sts store stack pointer stsb store low byte of 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 condition codes for jcc are as follows: 0000 extra condition code 0001 jeq - jump if zero 0010 jcs/jhs - jump if carry set (jump if higher or same unsigned) 0011 jmi - jump if negative set 0100 jvs - jump if overflow set 0101 jlt - jump if less than (signed) 0110 jle - jump if less than or equal to (signed) 0111 jls - jump if lower or same (unsigned) 1000 extra condition code 1001 jne - jump if not zero 1010 jcc/jlo - jump if carry clear (jump if lower unsigned) 1011 jpl - jump if positive 1100 jvc - jump if overflow clear 1101 jge - jump if greater than or equal (signed) 1110 jgt - jump if greater than (signed) 1111 jhi - jump if higher (unsigned) Reset conditions: - AC, SP and all flags are clear. - PC is loaded with FC00. - First instruction executed is at FC00. Software interrupt conditions: - AC/PC/Flags are pushed. - PC is loaded with FD00. - First instruction executed after BRK is at FD00. Hardware interrupt conditions: - AC/PC/Flags are pushed. - PC is loaded with FE00. - I-flag is cleared. - First instruction executed after IRQ is at FE00. Stack after PSH with all registers selected, BRK or IRQ: | | +-------------+ | MSB of AC | +-------------+ | LSB of AC | +-------------+ | MSB of PC | +-------------+ | LSB of PC | +-------------+ | junk | +-------------+ | Flags | <--- SP +-------------+ - Pushed PC is address of instruction following PSH or BRK, or first instruction to execute after a return from interrupt. Stack after JSR: | | +-------------+ | MSB of PC | +-------------+ | LSB of PC | <--- SP +-------------+ - Pushed PC is address of instruction following the JSR. Instruction timing: misc. instructions (r=read, w=write, d=dead): jmp direct: 4 (3r, 1d) jmp indirect: 6 (4r, 2d) jcc direct: 4 (3r, 1d) jsr direct: 5 (3r, 2w) jsr indirect: 7 (4r, 2w, 1d) push: (1d+2r+5w) 3+(2 for ac)+(2 for pc)+(1 for flags) (4 - 8 cycles) pop: (1d+7r) 3+(2 for ac)+(2 for pc)+(1 for flags) (4 - 8 cycles) brk/irq: 9 (2r, 5w, 2d) operate instructions: ac-stack byte: 4 (3r, 1d) ac-stack word: 5 (4r, 1d) ac-indexed byte: 7 (5r, 2d) ac-indexed word: 8 (6r, 2d) r.m.w. byte stack: 5 (3r, 1w, 1d) r.m.w. word stack: 7 (4r, 2w, 1d) r.m.w. byte indexed: 8 (5r, 1w, 2d) r.m.w. word indexed: 10 (6r, 2w, 2d) immediate byte: 2 (2r) immediate word: 3 (3r) Interrupt latency: Worst-case interrupt latency is 17 cycles (the longest instruction is 10 cycles and interrupt servicing takes 9 cycles, but 2 fetch cycles are skipped). Detailed instruction-set summary: Code Mnemonic Operation N Z I V C ------------ -------- --------- - - - - - 12 00 brk PC=PC+2, @--SP=AC, @--SP=PC, - - - - - @--SP=FLAGS, PC=FFD0 14 -----fpa pop ac,pc,cc PC=PC+2, FLAGS=@SP++, X X X X X PC=@SP++, AC=@SP++ - Only registers whoes bits are set are poped. 16 -----fpa psh ac,pc,cc - - - - - PC=PC+2, @--SP=AC, @--SP=PC, @--SP=FLAGS - Only registers whoes bits are set are pushed. 18 LL HH 00 jmp label PC=HHLL - - - - - 1A LL HH 00 jsr label PC=PC+2, @--SP=PC, - - - - - PC=HHLL 1C dd jmp [dd] PC=@(SP+dd) - - - - - 1E dd jsr [dd] PC=PC+2, @--SP=PC, - - - - - PC=@(SP+dd) 22 LL HH 00 jeq label if Z==1: PC=HHLL - - - - - else: PC=PC+2 24 LL HH 00 jcs label if C==1: PC=HHLL - - - - - else: PC=PC+2 26 LL HH 00 jmi label if N==1: PC=HHLL - - - - - else: PC=PC+2 28 LL HH 00 jvs label if V==1: PC=HHLL - - - - - else: PC=PC+2 2A LL HH 00 jlt label if (V^N)==1: PC=HHLL - - - - - else: PC=PC+2 2C LL HH 00 jle label if ((V^N)|Z)==1: PC=HHLL - - - - - else: PC=PC+2 2E LL HH 00 jls label if (~C | Z)==1: PC=HHLL - - - - - else: PC=PC+2 32 LL HH 00 jne label if Z==0: PC=HHLL - - - - - else: PC=PC+2 34 LL HH 00 jcc label if C==0: PC=HHLL - - - - - else: PC=PC+2 36 LL HH 00 jpl label if N==0: PC=HHLL - - - - - else: PC=PC+2 38 LL HH 00 jvc label if V==0: PC=HHLL - - - - - else: PC=PC+2 3A LL HH 00 jge label if (V^N)==0: PC=HHLL - - - - - else: PC=PC+2 3C LL HH 00 jgt label if ((V^N)|Z)==0: PC=HHLL - - - - - else: PC=PC+2 3E LL HH 00 jhi label if (~C | Z)==0: PC=HHLL - - - - - else: PC=PC+2 42 ii tstbx #ii SX(ii) X X - - - 44 ii orb #ii AC=(AC | ii) X X - - - 46 ii xorbx #ii AC=(AC ^ SX(ii)) X X - - - 48 ii bitb #ii (AC & ii) X X - - - 4A ii andbx #ii AC=(AC & SX(ii)) X X - - - 4C ii addb #ii AC=(AC+ii) X X - X X 4E ii addbx #ii AC=(AC+SX(ii)) X X - X X 50 ii cmpb #ii (AC-ii) X X - X X 52 ii cmpbx #ii (AC-SX(ii)) X X - X X 54 ii subb #ii AC=(AC-ii) X X - X X 56 ii subbx #ii AC=(AC-SX(ii)) X X - X X 58 ii ldab #ii AC=ii - - - - - 5A ii ldabx #ii AC=SX(ii) - - - - - 5C ii ldsb #ii SP=ii - - - - - 5E ii addsbx #ii SP=SP+SX(ii) - - - - - 62 ll hh 00 tst #hhll (hhll) X X - - - 64 ll hh 00 or #hhll AC=(AC | hhll) X X - - - 66 ll hh 00 xor #hhll AC=(AC ^ hhll) X X - - - 68 ll hh 00 bit #hhll (AC & hhll) X X - - - 6A ll hh 00 and #hhll AC=(AC & hhll) X X - - - 6C ll hh 00 add #hhll AC=(AC+hhll) X X - X X 6E ll hh 00 adc #hhll AC=(AC+hhll) X X - X X 70 ll hh 00 cmp #hhll (AC-hhll) X X - X X 72 ll hh 00 cwc #hhll (AC-hhll-~C) X X - X X 74 ll hh 00 sub #hhll AC=(AC-hhll) X X - X X 76 ll hh 00 sbc #hhll AC=(AC-hhll-~C) X X - X X 78 ll hh 00 lda #hhll AC=hhll - - - - - 7A ll hh 00 lda #hhll AC=hhll - - - - - 7C ll hh 00 lds #hhll SP=hhll - - - - - 7E ll hh 00 adds #hhll SP=SP+hhll - - - - - 43 dd tstbx dd SX(*(SP+dd)) X X - - - 45 dd orb dd AC=(AC | *(SP+dd)) X X - - - 47 dd xorbx dd AC=(AC ^ SX(*(SP+dd))) X X - - - 49 dd bitb dd (AC & *(SP+dd)) X X - - - 4B dd andbx dd AC=(AC & SX(*(SP+dd))) X X - - - 4D dd addb dd AC=(AC+*(SP+dd)) X X - X X 4F dd addbx dd AC=(AC+SX(*(SP+dd))) X X - X X 51 dd cmpb dd (AC-*(SP+dd)) X X - X X 53 dd cmpbx dd (AC-SX(*(SP+dd))) X X - X X 55 dd subb dd AC=(AC-*(SP+dd)) X X - X X 57 dd subbx dd AC=(AC-SX(*(SP+dd))) X X - X X 59 dd ldab dd AC=*(SP+dd) - - - - - 5B dd ldabx dd AC=SX(*(SP+dd)) - - - - - 5D dd ldsb dd SP=*(SP+dd) - - - - - 5F dd addsbx dd SP=SP+SX(*(SP+dd)) - - - - - 63 dd tst dd (@(SP+dd)) X X - - - 65 dd or dd AC=(AC | @(SP+dd)) X X - - - 67 dd xor dd AC=(AC ^ @(SP+dd)) X X - - - 69 dd bit dd (AC & @(SP+dd)) X X - - - 6B dd and dd AC=(AC & @(SP+dd)) X X - - - 6D dd add dd AC=(AC+@(SP+dd)) X X - X X 6F dd adc dd AC=(AC+@(SP+dd)) X X - X X 71 dd cmp dd (AC-@(SP+dd)) X X - X X 73 dd cwc dd (AC-@(SP+dd)-~C) X X - X X 75 dd sub dd AC=(AC-@(SP+dd)) X X - X X 77 dd sbc dd AC=(AC-@(SP+dd)-~C) X X - X X 79 dd lda dd AC=@(SP+dd) - - - - - 7B dd lda dd AC=@(SP+dd) - - - - - 7D dd lds dd SP=@(SP+dd) - - - - - 7F dd adds dd SP=SP+@(SP+dd) - - - - - C2 dd tstbx dd,r SX(*(@(SP+r)+dd)) X X - - - C4 dd orb dd,r AC=(AC | *(@(SP+r)+dd)) X X - - - C6 dd xorbx dd,r AC=(AC ^ SX(*(@(SP+r)+dd))) X X - - - C8 dd bitb dd,r (AC & *(@(SP+r)+dd)) X X - - - CA dd andbx dd,r AC=(AC & SX(*(@(SP+r)+dd))) X X - - - CC dd addb dd,r AC=(AC+*(@(SP+r)+dd)) X X - X X CE dd addbx dd,r AC=(AC+SX(*(@(SP+r)+dd))) X X - X X D0 dd cmpb dd,r (AC-*(@(SP+r)+dd)) X X - X X D2 dd cmpbx dd,r (AC-SX(*(@(SP+r)+dd))) X X - X X D4 dd subb dd,r AC=(AC-*(@(SP+r)+dd)) X X - X X D6 dd subbx dd,r AC=(AC-SX(*(@(SP+r)+dd))) X X - X X D8 dd ldab dd,r AC=*(@(SP+r)+dd) - - - - - DA dd ldabx dd,r AC=SX(*(@(SP+r)+dd)) - - - - - DC dd ldsb dd,r SP=*(@(SP+r)+dd) - - - - - DE dd addsbx dd,r SP=SP+SX(*(@(SP+r)+dd)) - - - - - E2 dd tst dd,r (@(@(SP+r)+dd)) X X - - - E4 dd or dd,r AC=(AC | @(@(SP+r)+dd)) X X - - - E6 dd xor dd,r AC=(AC ^ @(@(SP+r)+dd)) X X - - - E8 dd bit dd,r (AC & @(@(SP+r)+dd)) X X - - - EA dd and dd,r AC=(AC & @(@(SP+r)+dd)) X X - - - EC dd add dd,r AC=(AC+@(@(SP+r)+dd)) X X - X X EE dd adc dd,r AC=(AC+@(@(SP+r)+dd)) X X - X X F0 dd cmp dd,r (AC-@(@(SP+r)+dd)) X X - X X F2 dd cwc dd,r (AC-@(@(SP+r)+dd)-~C) X X - X X F4 dd sub dd,r AC=(AC-@(@(SP+r)+dd)) X X - X X F6 dd sbc dd,r AC=(AC-@(@(SP+dd))-~C) X X - X X F8 dd lda dd,r AC=@(@(SP+r)+dd) - - - - - FA dd lda dd,r AC=@(@(SP+r)+dd) - - - - - FC dd lds dd,r SP=@(@(SP+r)+dd) - - - - - FE dd adds dd,r SP=SP+@(@(SP+r)+dd) - - - - - 01 dd stab dd *(SP+dd)=AC - - - - - 03 dd stsb dd *(SP+dd)=SP - - - - - 05 dd lslb dd *(SP+dd)=(*(SP+dd)<<1) X X - X X 07 dd rolb dd *(SP+dd)=(*(SP+dd)<<1)+C X X - X X 09 dd lsrb dd *(SP+dd)=(*(SP+dd)>>1) X X - X X 0B dd rorb dd *(SP+dd)=(*(SP+dd)>>1) X X - X X 0D dd asrb dd *(SP+dd)=(*(SP+dd)>>1) X X - X X 0F dd comb dd *(SP+dd)=~(*(SP+dd)) X X - - - 11 dd negb dd *(SP+dd)=-(*(SP+dd)) X X - X X 13 dd cngb dd *(SP+dd)=~(*(SP+dd))+C X X - X X 15 dd decb dd *(SP+dd)=*(SP+dd)-1 X X - X X 17 dd csbb dd *(SP+dd)=*(SP+dd)-~C X X - X X 19 dd incb dd *(SP+dd)=*(SP+dd)+1 X X - X X 1B dd cadb dd *(SP+dd)=*(SP+dd)+C X X - X X 1D dd clrb dd *(SP+dd)=0 - - - - - 21 dd sta dd @(SP+dd)=AC - - - - - 23 dd sts dd @(SP+dd)=SP - - - - - 25 dd lsl dd @(SP+dd)=(@(SP+dd)<<1) X X - X X 27 dd rol dd @(SP+dd)=(@(SP+dd)<<1)+C X X - X X 29 dd lsr dd @(SP+dd)=(@(SP+dd)>>1) X X - X X 2B dd ror dd @(SP+dd)=(@(SP+dd)>>1) X X - X X 2D dd asr dd @(SP+dd)=(@(SP+dd)>>1) X X - X X 2F dd com dd @(SP+dd)=~(@(SP+dd)) X X - - - 31 dd neg dd @(SP+dd)=-(@(SP+dd)) X X - X X 33 dd cng dd @(SP+dd)=~(@(SP+dd))+C X X - X X 35 dd dec dd @(SP+dd)=@(SP+dd)-1 X X - X X 37 dd csb dd @(SP+dd)=@(SP+dd)-~C X X - X X 39 dd inc dd @(SP+dd)=@(SP+dd)+1 X X - X X 3B dd cad dd @(SP+dd)=@(SP+dd)+C X X - X X 3D dd clr dd @(SP+dd)=0 - - - - - 80 dd stab dd,r *(@(SP+r)+dd)=AC - - - - - 82 dd stsb dd,r *(@(SP+r)+dd)=SP - - - - - 84 dd lslb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)<<1) 86 dd rolb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)<<1)+C 88 dd lsrb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)>>1) 8A dd rorb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)>>1) 8C dd asrb dd,r *(@(SP+r)+dd)= (*(@(SP+r)+dd)>>1) X X - X X 8E dd comb dd,r *(@(SP+r)+dd)= ~(*(@(SP+r)+dd)) X X - - - 90 dd negb dd,r *(@(SP+r)+dd)= -(*(@(SP+r)+dd)) X X - X X 92 dd cngb dd,r *(@(SP+r)+dd)= ~(*(@(SP+r)+dd))+C X X - X X 94 dd decb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)-1 X X - X X 96 dd csbb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)-~C X X - X X 98 dd incb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)+1 X X - X X 9A dd cadb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)+C X X - X X 9C dd clrb dd,r *(@(SP+r)+dd)=0 - - - - - A0 dd sta dd,r @(@(SP+r)+dd)=AC - - - - - A2 dd sts dd,r @(@(SP+r)+dd)=SP - - - - - A4 dd lsl dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)<<1) X X - X X A6 dd rol dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)<<1)+C X X - X X A8 dd lsr dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)>>1) X X - 0 X AA dd ror dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)>>1) X X - 0 X AC dd asr dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)>>1) X X - 0 X AE dd com dd,r @(@(SP+r)+dd)= ~(@(@(SP+r)+dd)) X X - - - B0 dd neg dd,r @(@(SP+r)+dd)= -(@(@(SP+r)+dd)) X X - X X B2 dd cng dd,r @(@(SP+r)+dd)= ~(@(@(SP+r)+dd))+C X X - X X B4 dd dec dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)-1 X X - X X B6 dd csb dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)-~C X X - X X B8 dd inc dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)+1 X X - X X BA dd cad dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)+C X X - X X BC dd clr dd,r @(@(SP+r)+dd)=0 - - - - - Notes: SX(n) means that n is a byte which is sign-extended to a word. *(n) means retrieve/store byte from/to address n @(n) means retrieve/store word from/to address n X means flag is affected - means flag is not affected --n means to predecrement n n++ means to postincrement n r is two-bit stack-register selector. It is multiplied by 2 and added to the stack-pointer value to get the address of the stack register. See the Instruction encoding chart to see how this field is encoded. Microsequences -------------- { ... } denotes an optional componant. Jump group ---------- Indirect jmps: 1.d ar=[sp+dirbyte] 2.r read to dirlo, oddify ar Direct jmps: 3.r read to dirhi, { for jsrs: ar=sp=[sp-2] } { for jsrs: 4.w write alu, { direct: dor=[pc+2] }, { indirect: dor=[pc] }, oddify ar } 5.d/w { cctrue: ar=pc=[dirword+0] } { ccfalse: { direct: ar=[pc+2] }, { indirect: ar=[pc] }, { for jsrs: write dor } 6.r read to ir, oddify ar 7.r read to disp and dirlo, ar=pc=[pc+2], decode jmp direct: 4 cycles jmp indirect: 6 cycles jcc direct: 4 cycles jsr direct: 5 cycles jsr indirect: 7 cycles Operate group ------------- Indexed: 1.d ar=[rn+sp] 2.r read dirlo, oddify ar 3.r read dirhi Stack: 4.d { stack: ar=[dirbyte+sp] }, { indexed: ar=[dirword+disp] } 5.r read dirlo, { word: oddify ar }, { byte, no rmw: ar=pc }, { byte rmw: hold ar } { word: 6.r read dirhi, { no rmw: ar=pc }, evenify ar } { rmw: 7.w dor=[operate(dir)], write alu { byte: ar=pc }, { word: oddify ar } } { word rmw: 8.w write dor, ar=pc } 9.r read ir, oddify ar, { rm: ac=[operate(ac,dir)] } 10.r read disp and dirlo, ar=pc=[pc+2], decode rm byte stack: 4 cycles rm word stack: 5 cycles rm byte indexed: 7 cycles rm word indexed: 8 cycles rmw byte stack: 5 cycles rmw word stack: 7 cycles rmw byte indexed: 8 cycles rmw word indexed: 10 cycles Immediate group --------------- Word: 1.r read dirhi, ar=pc=[pc+2] Byte: 2.r read ir, ac=[operate(ac,dir)], oddify ar 3.r read disp and dirlo, ar=pc=[pc+2], decode byte immediate: 2 cycles word immediate: 3 cycles Push/Brk/Irq ------------ 1.d ar=sp=[sp-2] { push ac: 2.w write alu, dor=[ac], oddify ar 3.w write dor, ar=sp=[sp-2] } { push pc: 4.w write alu, dor=[pc], oddify ar 5.w write dor, ar=sp=[sp-2] } { push flags: 6.w write alu, dor=[flags], { no brk/irq: ar=pc } } { brk/irq: 7.d ar=pc=[brk/irq address] } 8.r read ir, oddify ar 9.r read dirlo and disp, ar=pc=[pc+2], decode cycles = 3 + (2 for ac) + (2 for pc) + (1 for flags) (4 - 8 cycles). Pop --- 1.d ar=[sp] { pop flags: 2.r read dirlo, ar=sp+[sp+2] } { pop pc: 3.r read dirlo, { if pop flags: flags=[dirword] }, oddify ar 4.r read dirhi, ar=sp=[sp+2] } { pop ac: 5.r read dirlo, { if pop pc: pc=[dirword] }, oddify ar 6.r read dirhi, ar=sp=[sp+2] } 7.r read ir, oddify ar, { if pop ac: ac=[dirword] } 8.r read dirlo and disp, ar=pc=[pc+2], decode cycles = 3 + (2 for ac) + (2 for pc) + (1 for flags) (4 - 8 cycles) Reset ----- 1.d ar=pc=[reset address] 2.r read ir, oddify ar 3.r read dirlo and disp, ar=pc=[pc+2], decode -- /* 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: 12827
Rickman wrote: > > Ad Verschueren wrote: > > > > "Glenn E. Hunt" <glennee@flash.net> writes: > > > > 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. > Well, it seems we are all letting our tools limit our thinking. I worked on a very large ASIC project in '94 & '95. We used VHDL, Model Tech for simulation, Autologic I for synthesis and LSI logic as the foundry. The ASIC I worked on was ~300K gates. I keep the design "structure free" by using the VHDL BLOCK Construct. Using this construct I was able to move functionality freely without breaking the design but still get the resolution I needed for floor planning. We all was said and done, I have one top module 6 lower modules and one big hairy math function library. So you have it right I represented 300K gates in 6 modules and one math library. Autologic I would synthesis hierarchy boundaries on the BLOCK statements; I didn't even have to put in the ports, and it worked great. Today, can anyone point me to a synthesis tool which supports BLOCKs? I didn't think so. More about my approach can be seen at: http://www.hdl-design.com Look for the papers section of the home page and find Design Super Con 97. We are all limited by our tools, but we need to demand that the vendors don't break things that use to work or could benefit us in the future. VHDL or Verilog Structure is tough to read, write or understand that is the reason that the graphical tools are making a comeback. "A picture is worth a 1000 words", still holds true. Tom Tessier -- +---------------------- http://www.hdl-design.com ---------------------+ : t2design : : 249 Lois Drive : : Louisville, CO 80027 : +------------------------ ---------------------- ----------------------+ : tomt@hdl-design.com * (303)665-6402 * Fax: (303)665-6431 : +------------------------ ---------------------- ----------------------+Article: 12828
jai kishan wrote: > Hi, > > I'm thinking of using a Xilinx Spartan XL FPGA to interface a 3.3V PCI > bus to a 5V local bus using the PCI logicore provided by Xilinx. Problem > is that once the PCI logicore is used it configures the device to switch > on diodes on all the I/O's to clamp to the 3.3V supply (as per the PCI > spec) but this causes the device to loose its 5V tolerance on all the > I/O's although otherwise the device is 5V tolerant. > > Any ideas? > > Thanks, > Jai. The 3.3v output from the spartan XL should be enough to drive your 5V I/Os on the local bus. Our board (HOT 2) is bundled with a version of the PCI Logic core. While the device that comes with the Logic Core is a 5V spartan we can place a spartan XL on the board which should fit into a 3.3V PCI (uses a universal PCI edge connector). http://www.xilinx.com/apps/xapp.htm xapp080. -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 12829
On spartan, you cain't use dem mode pins for I/O, which is why M1.x won't let you use them. There is only one mode pin on Spartan, as it only supports master serial and slave serial modes. That mode pin is about as useful as tits on a bull once the chip is configured. I haven't tried compiling one of my 4KE designs that use the mode pins under the M1.x tools. I already found that PPR in XACT6 does a better job for the 4KE parts. M1 doesn't permit certain packing combinations in the CLBs that are legal. It wouldn't surprise me if M1 also didn't support the mode pins on designs where they are legal. If this is the case, it is just one more example of taking away tool functionality we already had. I guess they do that to make room for the extra memory the tools need to run. SIGH. Steve Casselman wrote: > Be careful about using M0, M1, or M2 if > you plan to use the spartan. M1.5 will > not let you use the mode pins for anything. > > If you have not used init you might think > about that. > > -- > Steve Casselman, President > Virtual Computer Corporation > http://www.vcc.com -- -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: 12830
I've placed rev.2 on my ftp site, which contains fixes and a greatly enhanced description (including details of how the CPU works). This will be the last long post. Look at the ftp for complete information from now on. Trailing Edge 16 FPGA CPU (c) 1998 Joseph H. Allen rev.2 Change log: - Improved CPU description - Changed OP code for STA/STAB (it's 1111 instead of 0000). - RSH was not delayed properly going into carry selector. Todo: - Finish assembler - Maybe move right-shifter after ALU- then we can do RMW insns (except for sign-extension) on AC. - Maybe merge non-coincident control signals. Might make control section smaller, but will use more flip-flops. - Provide schematic for minimal system. Description: TE16 is a small free 16-bit CPU designed for Xilinx's low cost XC5200 series FPGAs. The minimal system would include an FPGA, a byte-wide ROM from which the FPGA loads its bitstream and which contains the CPU's boot program, a byte-wide RAM, and an oscillator. The idea here is to use whatever space remains in the FPGA for interesting peripherals, and thereby compete with traditional microcontrollers. The design goals for TE16 were low cost, small size and a powerful enough instruction set so that programming is straigtforward. - Sources located at ftp://ftp.worcester.com/joe/te16.zip - Fits in a Xilinx XC5204. *Almost* fits in a XC5202, I'm working on it. - Runs at 11MHz for the -5 part. Currently uses 178 FFs, and 266 FMAPs. The XC5202 has 256 FFs and 256 FMAPs. The XC5204 has 480 FFs and 480 FMAPs. - *.sch, OrCAD schematics. You need the Xilinx XACT FPGA library to edit them. - *.ps, Postscript version of these schematics. - te16.bin: Binary bitstream to load into prom. For XC5204 84-pin PLCC. - te16.rpt: Pin assignment report. Other te16.* files are other reports from Xilinx XACT. - Licensing: The sources are licensed under the Gnu-copyleft (see the file 'copying' for the full license). This means that you may freely use, distribute or sell them, but this license must remain intact, so that any buyer or recipient may also be able to freely redistribute or sell them. Any modifications must also be placed under the Gnu-copyleft and distributed for free. Of course there is no warranty that these sources will be useful or even work, and there will be no liability on my part should they cause anybody any problems. If you use this in a product, all I ask is that you print in the documentation which comes with your product: 'Uses Joe Allen's TE16 CPU'. External Pins & Signals: Internal FPGA point of view: i[7..0] data input bus o[7..0] data output bus a[15..0] address bus wr write line- indicates that data on o[7..0] should be written to address a[15..0] at end of current cycle. rd read line- indicates that data from address a[15..0] should be ready to be captured on i[7..0] by the end of the current cycle. irq interrupt request- asynchronous. IRQ should be held low until the software responds to the source of the interrupt. clk - primary clock. q - out of phase clock- should be 90 degrees early with respect to clk. This clock used only to prevent contention on the internal ALU-B bus. Bus output enable signals are latched on q, and are driven while clk is high. q could be eliminated (for an ASIC) by replacing the ALU-B bus with a mux. The select signals for the mux should come from flip-flops clocked by clk. External to FPGA point of view: d[7..0] tri-state data bus addr[15..0] address bus nwr low going write pulse (ram should save on rising edge) nrd low going read pulse (memory should output to bus while low) nirq interrupt request- hold low until serviced by software. clk and q are used to generate nwr and nrd from wr and rd as shown below: ______ ______ __ clk __ ______ ______ _____ ______ _____ q ______ ______ ____________ rd __ ______________ ____________ wr ______________ __ _____ ______________ nrd _________ _________________ _____ nwr ______ addr | addr n | addr n+1 | data ---------| in |--| out |- read cycle write cycle Write data occurs from falling edge of q to rising edge of clk. Nwr happens while q is low (nwr should be connected to RAM write enable lines). Read data should be driven while nrd is low. nrd occurs from q falling edge to clk rising edge. NRD should be connected to memory output enable lines). Registers: MSB LSB 15 . . . 5 4 3 2 1 0 +-------------------------------+ | | Accumulator +-------------------------------+ | 0| Stack pointer +-------------------------------+ | 0| Program counter +---------------------+---------+ |N Z I V C| Condition flags +---------+ N = negative, Z = zero, I = interrupt enable, V = overflow, C = carry C = 1 for carry after an add, 0 for no carry after an add C = 0 for borrow after a subtract, 1 for no borrow after subtract V = overflow: exclusive-or of carry going into and comming out of bit 15. - Stack pointer and program counter are always even (they only point to words). - The stack builds downwards (SP is predecremented for PSH, postincremented for POP). The stack pointer points to the first word on the stack. The first free word is at SP-2. Addressing modes: Register-memory instructions: Immediate, Stack, Indexed Read-modify-write instructions: Stack, Indexed Jump instructions: Direct, Indirect Immediate: An 8-bit or 16-bit literal operand value follows the instruction. Stack: The 8-bit or 16-bit data is on the stack. The address of the data is computed by adding an 8-bit unsigned value which is part of the instruction to the stack pointer. Direct: A 16-bit jump destination address follows the instruction. Indirect: A 16-bit jump destination is on the stack. The address of this value is computed by adding an 8-bit unsigned value which is part of the instruction to the stack pointer. Indexed: The 8-bit or 16-bit data is somewhere in memory. The address of the data is computed by adding a 7-bit unsigned value which value which is part of the instruction to one of the first four words on the stack (I.E., those words found at SP+0, SP+2, SP+4 or SP+6). A two-bit field within the instruction selects which of these four words is used. Memory format: +------------------+ | byte 0 LSB | \ +------------------+ word 0 | byte 1 MSB | / +------------------+ | byte 2 LSB | \ +------------------+ word 2 | byte 3 MSB | / +------------------+ | | . . . . . . | | +------------------+ | byte 65534 LSB | \ +------------------+ word 65534 | byte 65545 MSB | / +------------------+ - All words must be aligned on even address boundaries. - The least significant byte within each word is at the lower address (except 16-bit immediate values and direct jump addresses, see below). - Special addresses: FC00 - Reset entry point: PC is initialized to this value on reset FD00 - BRK instruction jumps to this address FE00 - IRQ instruction jumps to this address Instruction coding: - Instructions are either 2 or 4 bytes. - Instructions must begin on even addresses only. 0 1 2 3 --- --- --- --- 1mwaaaar rddddddd indexed 0mwaaaa1 dddddddd stack 011aaaa0 llllllll hhhhhhhh -------- immediate word 010aaaa0 iiiiiiii immediate byte 001cccc0 lllllll0 hhhhhhhh -------- jump on condition (jcc) 00011110 dddddddd jump to subroutine indirect (jsr) 00011100 dddddddd jump indirect (address on stack) 00011010 lllllll0 hhhhhhhh -------- jump to subroutine direct (jsr) 00011000 lllllll0 hhhhhhhh -------- jump direct (jmp) 00010110 -----fpa push registers (psh) 00010100 -----fpa pop registers (pop) 00010010 -------- software interrupt (brk) 00010000 -------- extra op-code space 0000---0 -------- extra op-code space Where: m=1: register-memory instructions m=0: read-modify-write instructions w=1: word operand w=0: byte operand cccc: condition code rr: stack register no. (first four stack words) ddddddd: 7-bit unsigned offset dddddddd: 8-bit unsigned offset iiiiiiii: 8-bit immediate value llllllll: Low byte of 16-bit immediate value of direct jump address hhhhhhhh: High byte of 16-bit immediate value or direct jump address a f p: accumulator, flags, program counter: i.e., which regs to push/pop ----: unused aaaa: read-modidy-write or register-memory op-code (see below) read-modify-write op-codes: 0001 sts store stack pointer stsb store low byte of 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 sta store accumulator word stab store accumulator byte register-memory (and register-immediate) op codes: 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 condition codes for jcc are as follows: 0000 extra condition code 0001 jeq - jump if zero 0010 jcs/jhs - jump if carry set (jump if higher or same unsigned) 0011 jmi - jump if negative set 0100 jvs - jump if overflow set 0101 jlt - jump if less than (signed) 0110 jle - jump if less than or equal to (signed) 0111 jls - jump if lower or same (unsigned) 1000 extra condition code 1001 jne - jump if not zero 1010 jcc/jlo - jump if carry clear (jump if lower unsigned) 1011 jpl - jump if positive 1100 jvc - jump if overflow clear 1101 jge - jump if greater than or equal (signed) 1110 jgt - jump if greater than (signed) 1111 jhi - jump if higher (unsigned) Reset conditions: - AC, SP and all flags are clear. - PC is loaded with FC00. - First instruction executed is at FC00. Software interrupt conditions: - AC/PC/Flags are pushed. - PC is loaded with FD00. - First instruction executed after BRK is at FD00. Hardware interrupt conditions: - AC/PC/Flags are pushed. - PC is loaded with FE00. - I-flag is cleared. - First instruction executed after IRQ is at FE00. Stack after PSH with all registers selected, BRK or IRQ: | | +-------------+ | MSB of AC | +-------------+ | LSB of AC | +-------------+ | MSB of PC | +-------------+ | LSB of PC | +-------------+ | junk | +-------------+ | Flags | <--- SP +-------------+ - Pushed PC is address of instruction following PSH or BRK, or first instruction to execute after a return from interrupt. Stack after JSR: | | +-------------+ | MSB of PC | +-------------+ | LSB of PC | <--- SP +-------------+ - Pushed PC is address of instruction following the JSR. Instruction timing: misc. instructions (r=read, w=write, d=dead): jmp direct: 4 (3r, 1d) jmp indirect: 6 (4r, 2d) jcc direct: 4 (3r, 1d) jsr direct: 5 (3r, 2w) jsr indirect: 7 (4r, 2w, 1d) push: (1d+2r+5w) 3+(2 for ac)+(2 for pc)+(1 for flags) (4-8 cycles) pop: (1d+7r) 3+(2 for ac)+(2 for pc)+(1 for flags) (4-8 cycles) brk/irq: 9 (2r, 5w, 2d) operate instructions: ac-stack byte: 4 (3r, 1d) ac-stack word: 5 (4r, 1d) ac-indexed byte: 7 (5r, 2d) ac-indexed word: 8 (6r, 2d) r.m.w. byte stack: 5 (3r, 1w, 1d) r.m.w. word stack: 7 (4r, 2w, 1d) r.m.w. byte indexed: 8 (5r, 1w, 2d) r.m.w. word indexed: 10 (6r, 2w, 2d) immediate byte: 2 (2r) immediate word: 3 (3r) Interrupt latency: Worst-case interrupt latency is 17 cycles (the longest instruction is 10 cycles and interrupt servicing takes 9 cycles, but 2 fetch cycles are skipped). Detailed instruction-set summary: Code Mnemonic Operation N Z I V C ------------ -------- --------- - - - - - 12 00 brk PC=PC+2, @--SP=AC, @--SP=PC, - - - - - @--SP=FLAGS, PC=FFD0 14 -----fpa pop ac,pc,cc PC=PC+2, FLAGS=@SP++, X X X X X PC=@SP++, AC=@SP++ - Only registers whoes bits are set are poped. 16 -----fpa psh ac,pc,cc - - - - - PC=PC+2, @--SP=AC, @--SP=PC, @--SP=FLAGS - Only registers whoes bits are set are pushed. 18 LL HH 00 jmp label PC=HHLL - - - - - 1A LL HH 00 jsr label PC=PC+2, @--SP=PC, - - - - - PC=HHLL 1C dd jmp [dd] PC=@(SP+dd) - - - - - 1E dd jsr [dd] PC=PC+2, @--SP=PC, - - - - - PC=@(SP+dd) 22 LL HH 00 jeq label if Z==1: PC=HHLL - - - - - else: PC=PC+2 24 LL HH 00 jcs label if C==1: PC=HHLL - - - - - else: PC=PC+2 26 LL HH 00 jmi label if N==1: PC=HHLL - - - - - else: PC=PC+2 28 LL HH 00 jvs label if V==1: PC=HHLL - - - - - else: PC=PC+2 2A LL HH 00 jlt label if (V^N)==1: PC=HHLL - - - - - else: PC=PC+2 2C LL HH 00 jle label if ((V^N)|Z)==1: PC=HHLL - - - - - else: PC=PC+2 2E LL HH 00 jls label if (~C | Z)==1: PC=HHLL - - - - - else: PC=PC+2 32 LL HH 00 jne label if Z==0: PC=HHLL - - - - - else: PC=PC+2 34 LL HH 00 jcc label if C==0: PC=HHLL - - - - - else: PC=PC+2 36 LL HH 00 jpl label if N==0: PC=HHLL - - - - - else: PC=PC+2 38 LL HH 00 jvc label if V==0: PC=HHLL - - - - - else: PC=PC+2 3A LL HH 00 jge label if (V^N)==0: PC=HHLL - - - - - else: PC=PC+2 3C LL HH 00 jgt label if ((V^N)|Z)==0: PC=HHLL - - - - - else: PC=PC+2 3E LL HH 00 jhi label if (~C | Z)==0: PC=HHLL - - - - - else: PC=PC+2 42 ii tstbx #ii SX(ii) X X - - - 44 ii orb #ii AC=(AC | ii) X X - - - 46 ii xorbx #ii AC=(AC ^ SX(ii)) X X - - - 48 ii bitb #ii (AC & ii) X X - - - 4A ii andbx #ii AC=(AC & SX(ii)) X X - - - 4C ii addb #ii AC=(AC+ii) X X - X X 4E ii addbx #ii AC=(AC+SX(ii)) X X - X X 50 ii cmpb #ii (AC-ii) X X - X X 52 ii cmpbx #ii (AC-SX(ii)) X X - X X 54 ii subb #ii AC=(AC-ii) X X - X X 56 ii subbx #ii AC=(AC-SX(ii)) X X - X X 58 ii ldab #ii AC=ii - - - - - 5A ii ldabx #ii AC=SX(ii) - - - - - 5C ii ldsb #ii SP=ii - - - - - 5E ii addsbx #ii SP=SP+SX(ii) - - - - - 62 ll hh 00 tst #hhll (hhll) X X - - - 64 ll hh 00 or #hhll AC=(AC | hhll) X X - - - 66 ll hh 00 xor #hhll AC=(AC ^ hhll) X X - - - 68 ll hh 00 bit #hhll (AC & hhll) X X - - - 6A ll hh 00 and #hhll AC=(AC & hhll) X X - - - 6C ll hh 00 add #hhll AC=(AC+hhll) X X - X X 6E ll hh 00 adc #hhll AC=(AC+hhll) X X - X X 70 ll hh 00 cmp #hhll (AC-hhll) X X - X X 72 ll hh 00 cwc #hhll (AC-hhll-~C) X X - X X 74 ll hh 00 sub #hhll AC=(AC-hhll) X X - X X 76 ll hh 00 sbc #hhll AC=(AC-hhll-~C) X X - X X 78 ll hh 00 lda #hhll AC=hhll - - - - - 7A ll hh 00 lda #hhll AC=hhll - - - - - 7C ll hh 00 lds #hhll SP=hhll - - - - - 7E ll hh 00 adds #hhll SP=SP+hhll - - - - - 43 dd tstbx dd SX(*(SP+dd)) X X - - - 45 dd orb dd AC=(AC | *(SP+dd)) X X - - - 47 dd xorbx dd AC=(AC ^ SX(*(SP+dd))) X X - - - 49 dd bitb dd (AC & *(SP+dd)) X X - - - 4B dd andbx dd AC=(AC & SX(*(SP+dd))) X X - - - 4D dd addb dd AC=(AC+*(SP+dd)) X X - X X 4F dd addbx dd AC=(AC+SX(*(SP+dd))) X X - X X 51 dd cmpb dd (AC-*(SP+dd)) X X - X X 53 dd cmpbx dd (AC-SX(*(SP+dd))) X X - X X 55 dd subb dd AC=(AC-*(SP+dd)) X X - X X 57 dd subbx dd AC=(AC-SX(*(SP+dd))) X X - X X 59 dd ldab dd AC=*(SP+dd) - - - - - 5B dd ldabx dd AC=SX(*(SP+dd)) - - - - - 5D dd ldsb dd SP=*(SP+dd) - - - - - 5F dd addsbx dd SP=SP+SX(*(SP+dd)) - - - - - 63 dd tst dd (@(SP+dd)) X X - - - 65 dd or dd AC=(AC | @(SP+dd)) X X - - - 67 dd xor dd AC=(AC ^ @(SP+dd)) X X - - - 69 dd bit dd (AC & @(SP+dd)) X X - - - 6B dd and dd AC=(AC & @(SP+dd)) X X - - - 6D dd add dd AC=(AC+@(SP+dd)) X X - X X 6F dd adc dd AC=(AC+@(SP+dd)) X X - X X 71 dd cmp dd (AC-@(SP+dd)) X X - X X 73 dd cwc dd (AC-@(SP+dd)-~C) X X - X X 75 dd sub dd AC=(AC-@(SP+dd)) X X - X X 77 dd sbc dd AC=(AC-@(SP+dd)-~C) X X - X X 79 dd lda dd AC=@(SP+dd) - - - - - 7B dd lda dd AC=@(SP+dd) - - - - - 7D dd lds dd SP=@(SP+dd) - - - - - 7F dd adds dd SP=SP+@(SP+dd) - - - - - C2 dd tstbx dd,r SX(*(@(SP+r)+dd)) X X - - - C4 dd orb dd,r AC=(AC | *(@(SP+r)+dd)) X X - - - C6 dd xorbx dd,r AC=(AC ^ SX(*(@(SP+r)+dd))) X X - - - C8 dd bitb dd,r (AC & *(@(SP+r)+dd)) X X - - - CA dd andbx dd,r AC=(AC & SX(*(@(SP+r)+dd))) X X - - - CC dd addb dd,r AC=(AC+*(@(SP+r)+dd)) X X - X X CE dd addbx dd,r AC=(AC+SX(*(@(SP+r)+dd))) X X - X X D0 dd cmpb dd,r (AC-*(@(SP+r)+dd)) X X - X X D2 dd cmpbx dd,r (AC-SX(*(@(SP+r)+dd))) X X - X X D4 dd subb dd,r AC=(AC-*(@(SP+r)+dd)) X X - X X D6 dd subbx dd,r AC=(AC-SX(*(@(SP+r)+dd))) X X - X X D8 dd ldab dd,r AC=*(@(SP+r)+dd) - - - - - DA dd ldabx dd,r AC=SX(*(@(SP+r)+dd)) - - - - - DC dd ldsb dd,r SP=*(@(SP+r)+dd) - - - - - DE dd addsbx dd,r SP=SP+SX(*(@(SP+r)+dd)) - - - - - E2 dd tst dd,r (@(@(SP+r)+dd)) X X - - - E4 dd or dd,r AC=(AC | @(@(SP+r)+dd)) X X - - - E6 dd xor dd,r AC=(AC ^ @(@(SP+r)+dd)) X X - - - E8 dd bit dd,r (AC & @(@(SP+r)+dd)) X X - - - EA dd and dd,r AC=(AC & @(@(SP+r)+dd)) X X - - - EC dd add dd,r AC=(AC+@(@(SP+r)+dd)) X X - X X EE dd adc dd,r AC=(AC+@(@(SP+r)+dd)) X X - X X F0 dd cmp dd,r (AC-@(@(SP+r)+dd)) X X - X X F2 dd cwc dd,r (AC-@(@(SP+r)+dd)-~C) X X - X X F4 dd sub dd,r AC=(AC-@(@(SP+r)+dd)) X X - X X F6 dd sbc dd,r AC=(AC-@(@(SP+dd))-~C) X X - X X F8 dd lda dd,r AC=@(@(SP+r)+dd) - - - - - FA dd lda dd,r AC=@(@(SP+r)+dd) - - - - - FC dd lds dd,r SP=@(@(SP+r)+dd) - - - - - FE dd adds dd,r SP=SP+@(@(SP+r)+dd) - - - - - 03 dd stsb dd *(SP+dd)=SP - - - - - 05 dd lslb dd *(SP+dd)=(*(SP+dd)<<1) X X - X X 07 dd rolb dd *(SP+dd)=(*(SP+dd)<<1)+C X X - X X 09 dd lsrb dd *(SP+dd)=(*(SP+dd)>>1) X X - X X 0B dd rorb dd *(SP+dd)=(*(SP+dd)>>1) X X - X X 0D dd asrb dd *(SP+dd)=(*(SP+dd)>>1) X X - X X 0F dd comb dd *(SP+dd)=~(*(SP+dd)) X X - - - 11 dd negb dd *(SP+dd)=-(*(SP+dd)) X X - X X 13 dd cngb dd *(SP+dd)=~(*(SP+dd))+C X X - X X 15 dd decb dd *(SP+dd)=*(SP+dd)-1 X X - X X 17 dd csbb dd *(SP+dd)=*(SP+dd)-~C X X - X X 19 dd incb dd *(SP+dd)=*(SP+dd)+1 X X - X X 1B dd cadb dd *(SP+dd)=*(SP+dd)+C X X - X X 1D dd clrb dd *(SP+dd)=0 - - - - - 1F dd stab dd *(SP+dd)=AC - - - - - 23 dd sts dd @(SP+dd)=SP - - - - - 25 dd lsl dd @(SP+dd)=(@(SP+dd)<<1) X X - X X 27 dd rol dd @(SP+dd)=(@(SP+dd)<<1)+C X X - X X 29 dd lsr dd @(SP+dd)=(@(SP+dd)>>1) X X - X X 2B dd ror dd @(SP+dd)=(@(SP+dd)>>1) X X - X X 2D dd asr dd @(SP+dd)=(@(SP+dd)>>1) X X - X X 2F dd com dd @(SP+dd)=~(@(SP+dd)) X X - - - 31 dd neg dd @(SP+dd)=-(@(SP+dd)) X X - X X 33 dd cng dd @(SP+dd)=~(@(SP+dd))+C X X - X X 35 dd dec dd @(SP+dd)=@(SP+dd)-1 X X - X X 37 dd csb dd @(SP+dd)=@(SP+dd)-~C X X - X X 39 dd inc dd @(SP+dd)=@(SP+dd)+1 X X - X X 3B dd cad dd @(SP+dd)=@(SP+dd)+C X X - X X 3D dd clr dd @(SP+dd)=0 - - - - - 3F dd sta dd @(SP+dd)=AC - - - - - 82 dd stsb dd,r *(@(SP+r)+dd)=SP - - - - - 84 dd lslb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)<<1) 86 dd rolb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)<<1)+C 88 dd lsrb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)>>1) 8A dd rorb dd,r *(@(SP+r)+dd)= X X - X X (*(@(SP+r)+dd)>>1) 8C dd asrb dd,r *(@(SP+r)+dd)= (*(@(SP+r)+dd)>>1) X X - X X 8E dd comb dd,r *(@(SP+r)+dd)= ~(*(@(SP+r)+dd)) X X - - - 90 dd negb dd,r *(@(SP+r)+dd)= -(*(@(SP+r)+dd)) X X - X X 92 dd cngb dd,r *(@(SP+r)+dd)= ~(*(@(SP+r)+dd))+C X X - X X 94 dd decb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)-1 X X - X X 96 dd csbb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)-~C X X - X X 98 dd incb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)+1 X X - X X 9A dd cadb dd,r *(@(SP+r)+dd)= *(@(SP+r)+dd)+C X X - X X 9C dd clrb dd,r *(@(SP+r)+dd)=0 - - - - - 9E dd stab dd,r *(@(SP+r)+dd)=AC - - - - - A2 dd sts dd,r @(@(SP+r)+dd)=SP - - - - - A4 dd lsl dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)<<1) X X - X X A6 dd rol dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)<<1)+C X X - X X A8 dd lsr dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)>>1) X X - 0 X AA dd ror dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)>>1) X X - 0 X AC dd asr dd,r @(@(SP+r)+dd)= (@(@(SP+r)+dd)>>1) X X - 0 X AE dd com dd,r @(@(SP+r)+dd)= ~(@(@(SP+r)+dd)) X X - - - B0 dd neg dd,r @(@(SP+r)+dd)= -(@(@(SP+r)+dd)) X X - X X B2 dd cng dd,r @(@(SP+r)+dd)= ~(@(@(SP+r)+dd))+C X X - X X B4 dd dec dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)-1 X X - X X B6 dd csb dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)-~C X X - X X B8 dd inc dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)+1 X X - X X BA dd cad dd,r @(@(SP+r)+dd)= @(@(SP+r)+dd)+C X X - X X BC dd clr dd,r @(@(SP+r)+dd)=0 - - - - - BE dd sta dd,r @(@(SP+r)+dd)=AC - - - - - Notes: SX(n) means that n is a byte which is sign-extended to a word. *(n) means retrieve/store byte from/to address n @(n) means retrieve/store word from/to address n X means flag is affected - means flag is not affected --n means to predecrement n n++ means to postincrement n r is two-bit stack-register selector. It is multiplied by 2 and added to the stack-pointer value to get the address of the stack register. See the Instruction encoding chart to see how this field is encoded. Cpu Structure ------------- Data paths: The CPU has the following structures. The source and control signals for each structure are indicated. DIR - 16-bit data input register Fed by: 8-bit data bus. Both halves of the DIR are fed by the bus. Signals: cedir - captures the lower half at the end of current cycle. hi - captures the upper half at end of current cycle. IR - 8-bit instruction register Fed by: 8-bit data input bus Signals: ceir - captures the data bus at end of current cycle. DISP - 7-bit displacement register Fed by: 8-bit data bus. Uppermost bit is always zero. Signals: ceir - captures the data bus at end of next cycle. busdisp - DISP drives ALU B bus during next cycle. CONST - 16-bit constant generator Signals: buszero - Drive 0 on ALU B bus during next cycle. busbrk - Drive BRK address on ALU B bus during next cycle. busirq - Drive IRQ address on ALU B bus during next cycle. busrst - Drive RESET address on ALU B bus during next cycle. SEX - Sign extender Fed by: DIR, IR (for rn field) Signals: word - pass 16-bit word next cycle. byte - pass 8-bit byte next cycle. sx - sign extend- only valid if byte is set. sign-extend next cycle. two - output the value of 2 next cycle. rn - output 'rr' field times 2 next cycle. (default) - output zero next cycle. RSHIFT - Right shifter Fed by: SEX, Carry Signals: rsh - right shift next cycle com - complement next cycle (default) - pass unchanged next cycle ror - enable carry for next cycle (only cares if rsh set) asr - sign extend next cycle (only cares if rsh set) word - if not set, right shift byte next cycle (only cares if rsh set). ALU - Arithmetic Logic Unit Fed by: A-side from RSHIFT, B-side from ALU B BUS, Carry Signals: These signals control what the ALU does next cycle: Choose one of: lsh - left-shift rsb - reverse-subtract (A-B-~C) and - logical and or - logical or xor - exclusive or (default) - add (A+B+C) Modifiers: cen - enable carry input (it's zero otherwise) cinv - invert carry input (if cen is low, carry is taken as 1 if this is set). Flags - Flag bits Fed by: ALU, RSHIFT (getting carry from RSH), SEQ (for clearing I-flag) Signals: ceflags - flags loaded from ALU output at end of this cycle. busflags - flags drive ALU-B BUS next cycle cv - Carry/Overflow flags affected by ALU result this cycle If rsh is high, C comes from right shifter instead of ALU. zn - Zero/Negative flags affected by ALU result this cycle cli - Clear interrupt enable flag at end of this cycle AC - Accumulator Fed by: ALU Signals: ceac - save alu result at end of current cycle busac - AC drives ALU-B bus next cycle SP - Stack pointer (15-bit, LSB is always 0) Fed by: ALU Signals: cesp - save alu result at end of current cycle bussp - SP drives ALU-B bus next cycle PC - Program counter (15-bit, LSB is always 0) Fed by: ALU Signals: cepc - save alu result at end of current cycle buspc - PC drive ALU-B bus next cycle AR - Address output register (16-bit) Fed by: ALU, PC Signals: cear - capture ALU result or PC at end of current cycle arpc - selects PC instead of ALU result arodd - cause AR to become odd at end of current cycle. it then becomes even on the cycle which follows. DOR - Data output register (8-bit) Fed by: ALU Signals: cedor - capture upper half of ALU result at end of current cycle. odd - Data output bus is driven from DOR. If low, output bus is driven from lower half of ALU result directly. WR - Write line (indicates a write cycle to external memory) Signals: cedor, arodd Cedor causes write to go high this cycle and next cycle too if arodd is also set. RD - Read line (indicates a read cycle to external memory) Signals: cedir, ceir, arodd Cedir and ceir cause read to go high this cycle and next cycle too if arodd is also set. Conrol section: These data path structures give rise to the following 39 control signals: cepc, ceir, cedir, cedor, cear, ceflags, ceac, cesp, buspc, bussp, busdisp, busac, busflags, buszero, busreset, busirq, busbrk, arpc, two, rn, cli, hi, arodd, and, or, xor, rsb, lsh, cen, cinv, rsh, ror, asr, com, word, byte, sx, zn, cv. Note that the control signals do not all have meaning for the same cycle. The follow signals must be asserted one cycle early to coincide with the remaining signals: buspc, bussp, busdisp, busac, busflags, buszero, busreset, busirq, busbrk, two, rn, arodd, and, or xor, rsb, lsh, cen, cinv, rsh, ror, asr, com, word, byte, sx. So to add 2 to the PC, the following sequence is needed: cycle 1: buspc, two cycle 2: cepc - Operation actually occurs during this cycle. This adds complexity (and size) to the microsequencer, so I may add flip-flops to all the lines so that they all coincide. The microsequencer (SEQ) is actually 7 one-hot bit state machines. Each state machine handles a group of common instructions. Any control signal which originates from more than one state machine must OR together each source. These OR gates can use quite a lot of FMAPs, so it is advantageous to have fewer complex state machines, than a larger number of simple state machines. There is also an operation code decoder, which selects which of the RMW and RM operation is to be performed, and what the source and destination of the operation is. This decoder is active during the appropriate cycle as indicated by the 'rm' and 'rmw' signals. Note that the decoder is structures to efficiently use 4-bit FMAPs. Microsequences -------------- { ... } denotes an optional componant (dependant on which instruction is given). [ ] indicates a componant which must be asserted one cycle early. Jump group ---------- Indirect jmps: 1.d ar=[sp+dirbyte] 2.r read to dirlo, oddify ar Direct jmps: 3.r read to dirhi, { for jsrs: ar=sp=[sp-2] } { for jsrs: 4.w write alu, { direct: dor=[pc+2] }, { indirect: dor=[pc] }, oddify ar } 5.d/w { cctrue: ar=pc=[dirword+0] } { ccfalse: { direct: ar=[pc+2] }, { indirect: ar=[pc] }, { for jsrs: write dor } 6.r read to ir, oddify ar 7.r read to disp and dirlo, ar=pc=[pc+2], decode jmp direct: 4 cycles jmp indirect: 6 cycles jcc direct: 4 cycles jsr direct: 5 cycles jsr indirect: 7 cycles Operate group ------------- Indexed: 1.d ar=[rn+sp] 2.r read dirlo, oddify ar 3.r read dirhi Stack: 4.d { stack: ar=[dirbyte+sp] }, { indexed: ar=[dirword+disp] } 5.r read dirlo, { word: oddify ar }, { byte, no rmw: ar=pc }, { byte rmw: hold ar } { word: 6.r read dirhi, { no rmw: ar=pc }, evenify ar } { rmw: 7.w dor=[operate(dir)], write alu { byte: ar=pc }, { word: oddify ar } } { word rmw: 8.w write dor, ar=pc } 9.r read ir, oddify ar, { rm: ac=[operate(ac,dir)] } 10.r read disp and dirlo, ar=pc=[pc+2], decode rm byte stack: 4 cycles rm word stack: 5 cycles rm byte indexed: 7 cycles rm word indexed: 8 cycles rmw byte stack: 5 cycles rmw word stack: 7 cycles rmw byte indexed: 8 cycles rmw word indexed: 10 cycles Immediate group --------------- Word: 1.r read dirhi, ar=pc=[pc+2] Byte: 2.r read ir, ac=[operate(ac,dir)], oddify ar 3.r read disp and dirlo, ar=pc=[pc+2], decode byte immediate: 2 cycles word immediate: 3 cycles Push/Brk/Irq ------------ 1.d ar=sp=[sp-2] { push ac: 2.w write alu, dor=[ac], oddify ar 3.w write dor, ar=sp=[sp-2] } { push pc: 4.w write alu, dor=[pc], oddify ar 5.w write dor, ar=sp=[sp-2] } { push flags: 6.w write alu, dor=[flags], { no brk/irq: ar=pc } } { brk/irq: 7.d ar=pc=[brk/irq address] } 8.r read ir, oddify ar 9.r read dirlo and disp, ar=pc=[pc+2], decode cycles = 3 + (2 for ac) + (2 for pc) + (1 for flags) (4 - 8 cycles). Pop --- 1.d ar=[sp] { pop flags: 2.r read dirlo, ar=sp+[sp+2] } { pop pc: 3.r read dirlo, { if pop flags: flags=[dirword] }, oddify ar 4.r read dirhi, ar=sp=[sp+2] } { pop ac: 5.r read dirlo, { if pop pc: pc=[dirword] }, oddify ar 6.r read dirhi, ar=sp=[sp+2] } 7.r read ir, oddify ar, { if pop ac: ac=[dirword] } 8.r read dirlo and disp, ar=pc=[pc+2], decode cycles = 3 + (2 for ac) + (2 for pc) + (1 for flags) (4 - 8 cycles) Reset ----- 1.d ar=pc=[reset address] 2.r read ir, oddify ar 3.r read dirlo and disp, ar=pc=[pc+2], decode Operation Decode ---------------- Register-Memory Codes: CODE OP BSRC FLAGS SAVE SX ASRC ALU CRY ---- --- ---- ----- ---- -- ---- --- --- 0000 nop - - - - pass add 0 0001 tst - ZN - X pass add 0 0010 or ac ZN ac - pass or 0 0011 xor ac ZN ac X pass xor 0 0100 bit ac ZN - - pass and 0 0101 and ac ZN ac X pass and 0 0110 add ac ZNCV ac - pass add 0 0111 adc ac ZNCV ac X pass add 0 for byte, C for word 1000 cmp ac ZNCV - - com add 1 1001 cwc ac ZNCV - X com add 1 for byte, C for word 1010 sub ac ZNCV ac - com add 1 1011 sbc ac ZNCV ac X com add 1 for byte, C for word 1100 lda - - ac - pass add 0 1101 lda - - ac X pass add 0 1110 lds - - sp - pass add 0 1111 adds sp - sp X pass add 0 Read-modify-write Codes: CODE OP BSRC ALU ALUCRY ASRC RSHCRY FLAGS ---- --- ---- --- ------ ---- ------ ----- 0000 nop - add 0 0 - - 0001 sts SP add 0 0 - - 0010 lsl - lsh 0 pass - CVZN 0011 rol - lsh C pass - CVZN 0100 lsr - add 0 rsh 0 CVZN 0101 ror - add 0 rsh C CVZN 0110 asr - add 0 rsh asr CVZN 0111 com - add 0 com - ZN 1000 neg - add 1 com - CVZN 1001 cng - add C com - CVZN 1010 dec - rsb 0 pass - CVZN 1011 csb - rsb C pass - CVZN 1100 inc - add 1 pass - CVZN 1101 cad - add C pass - CVZN 1110 clr - add 0 0 - - 1111 sta AC add 0 0 - - -- /* 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: 12831
jmccarty@sun1307.spd.dsccc.com (Mike McCarty) writes: > )Hope this helps! > > No, it didn't. If you look, you'll see that I work for a major > manufacturer of telephony equipment. So I fully understand the use of > specialty little CPUs made from programmable logic, having used them a > few times myself. Ah! A man with interesting knowledge! > I wanted to know about *this* device. It doesn't seem to excel at > anything, so I don't see the particular advantage to it, and it isn't > cheap (for the hobbiest types). OK, so you know of simple CPUs that can be made from programmable logic and that *do* excel at something. Perhaps you would be so kind as to present your favourite design, or provide public pointers to it? -- Bruce -- 'We have no intention of shipping another bloated operating system and forcing that down the throats of our Windows customers' -- Paul Maritz, Microsoft Group Vice PresidentArticle: 12832
In article <F1oL4y.60I@world.std.com>, Joseph H Allen <jhallen@world.std.com> wrote: > - Changed OP code for STA/STAB (it's 1111 instead of 0000). IMHO, opcode 1111 and opcode 0000 should be designed to do something critical that will lead to an immediate trap or observable and trappable mode change, so if you jump to uninitialized ROM or RAM you know THEN. One of the nice things about the PDP-11 is that 0 is HALT. One of the annoying things baout the 1802 is that FF is Subtract Memory Immediate. As an aside, your license seems to be a combination of the GPL and the Berkeley "attribution" copyright. You might want to pick one or the other, or even the LGPL. -- In hoc signo hack, Peter da Silva <peter@baileynm.com> `-_-' "Heb jij vandaag je wolf al geaaid?" 'U` "Tell init(8) to lock-n-load, we're goin' zombie slaying!"Article: 12833
On Sun, 1 Nov 1998 00:32:50 +0000, Edward Moore <edmoore@edmoore.demon.co.uk> wrote: >Exemplar Leonardo supports blocks, and a whole lot of other stuff too. >The only thing it objects to that I would find useful is a declarative >region inside a GENERATE statement (VHDL'93 only), so you don't need to >do: > block_name : BLOCK > SIGNAL local_signal : STD_LOGIC; > BEGIN > generate_name : IF condition THEN GENERATE > -- code > END GENERATE; > END BLOCK; > >but could just do: > > generate_name : IF condition THEN GENERATE > SIGNAL local_signal : STD_LOGIC; > -- code > END GENERATE; i just tried this on leo 4.1.3 without problems - i presume that your 'THEN' is a typo, and not the cause of the original problem? exemplar does have a problem with attribute declarations in a generate declarative region (they're only evaluated once, instead of on every iteration), but that's another story. evanArticle: 12834
Steve Casselman wrote: > > jai kishan wrote: > > > Hi, > > > > I'm thinking of using a Xilinx Spartan XL FPGA to interface a 3.3V PCI > > bus to a 5V local bus using the PCI logicore provided by Xilinx. Problem > > is that once the PCI logicore is used it configures the device to switch > > on diodes on all the I/O's to clamp to the 3.3V supply (as per the PCI > > spec) but this causes the device to loose its 5V tolerance on all the > > I/O's although otherwise the device is 5V tolerant. > > > > Any ideas? > > > > Thanks, > > Jai. > > The 3.3v output from the spartan XL should be enough > to drive your 5V I/Os on the local bus. Our board (HOT 2) > is bundled with a version of the PCI Logic core. While the > device that comes with the Logic Core is a 5V spartan we > can place a spartan XL on the board which should fit into > a 3.3V PCI (uses a universal PCI edge connector). > http://www.xilinx.com/apps/xapp.htm > xapp080. > > -- > Steve Casselman, President > Virtual Computer Corporation > http://www.vcc.com But still the XL devices with the clamping diodes would harm the 5V drivers on the local side and now I can't have a 2.5V supply for the Virtex series. I was thinking that leaving the clamping diodes unconnected would not make any difference to the PCI signal integrity. My worst case PCI system would be 1>host-PCI bridge, 2> XLfpga used for target interface between PCI and local processor and 3>an unpopulated PCI connector.(Other case would be a populated connector with a PCI device which does have the clamping diodes) Any comments?Article: 12835
Don't know what to tell you. For you I am sure it is troubling, for me it is a disaster. Have FUN!! Nick (Formally X FAE for Marshall) JPIQ wrote: > I just lost my source for Xilinx, Marshall. I hear Lattice dropped Insight. > It seems as if the industry in playing musical chairs with their resellers. So > why the big shake up and when will it stop? I do not want to start a project > with one reseller and have to finish it with another and explain what I am > doing all over again. > > Any clues? > JimArticle: 12836
In article <363A6C58.7328FF76@hdl-design.com>, "Thomas D. Tessier" <tomt@hdl-design.com> writes >..... >Today, can anyone point me to a synthesis tool which supports BLOCKs? I >didn't think so. > >More about my approach can be seen at: >http://www.hdl-design.com >Look for the papers section of the home page and find Design Super Con >97. > >We are all limited by our tools, but we need to demand that the vendors >don't break things that use to work or could benefit us in the future. > >VHDL or Verilog Structure is tough to read, write or understand that is >the reason that the graphical tools are making a comeback. "A picture is >worth a 1000 words", still holds true. > >Tom Tessier Exemplar Leonardo supports blocks, and a whole lot of other stuff too. The only thing it objects to that I would find useful is a declarative region inside a GENERATE statement (VHDL'93 only), so you don't need to do: block_name : BLOCK SIGNAL local_signal : STD_LOGIC; BEGIN generate_name : IF condition THEN GENERATE -- code END GENERATE; END BLOCK; but could just do: generate_name : IF condition THEN GENERATE SIGNAL local_signal : STD_LOGIC; -- code END GENERATE; -- Edward Moore Snell & Willcox Ltd Essex U.K Ed.Moore@snellwillcox.comArticle: 12837
Steve Casselman <sc@vcc.com> wrote: >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. The primary question that I have about the latter technique is how do you go about selecting the initial primitives? I am new to genetic algorithms, but they seem to require that the person setting up the problem already have a good idea of which primitive actions to start with. -- John F. Eldredge -- eldredge@poboxes.com PGP key available from http://www.netforward.com/poboxes/?eldredge/ -- "There must be, not a balance of power, but a community of power; not organized rivalries, but an organized common peace." - Woodrow WilsonArticle: 12838
John F. Eldredge eldredge@poboxes.com wrote: >The primary question that I have about the latter technique is how do >you go about selecting the initial primitives? I am new to genetic >algorithms, but they seem to require that the person setting up the >problem already have a good idea of which primitive actions to start >with. Using an educated guess usually allows the algorithm to work faster. However, it is not dependant. There are some cases where it helps tremendously. For example -- a GA that's writing a program. (see Koza 1992) -- Thamer Al-Herbish <URL http://www.whitefang.com/> [ The Raw IP Networking FAQ <URL http://www.whitefang.com/rin/ > ]Article: 12839
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE0591.6F87E239 Content-Type: text/plain; charset="koi8-r" Hi All, I would appreciate very much, if somebody would share his experience: What types of step-down voltage regulators can be used to convert 5 Volts to 3.3 (2.5) Volts to power XILINX chips? What are part numbers of the suitable voltage regulators? Thanks, Alex Sherstuk Sherstuk@amsd.com ------_=_NextPart_001_01BE0591.6F87E239 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dkoi8-r"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2232.0"> <TITLE>Q: 3.3 V regulators suitable for XILINX - ?</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2 FACE=3D"Arial">Hi All,</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial"> I would appreciate very = much, if somebody would share</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">his experience:</FONT>=20 <BR><FONT SIZE=3D2 FACE=3D"Arial CYR"> What types of = step-down voltage regulators can be used</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial CYR">to convert 5 Volts to = 3</FONT><FONT SIZE=3D2 FACE=3D"Arial">.3 (2.5)</FONT><FONT SIZE=3D2 = FACE=3D"Arial CYR"> Volts to power XILINX chips?</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial CYR">What are part numbers of the = suitable voltage regulators?</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial CYR">Thanks,</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial CYR"> Alex Sherstuk</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial"> = Sherstuk@amsd.com</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01BE0591.6F87E239--Article: 12840
How does it compare with the MicroChip PIC devices. My personal suspicion is that the PIC devices are smaller (probably), cheaper (certainly), faster (probably), more peripherals such as timers/adc/dac/etc (certainly), more software support (certainly). Any corrections to the above suspicions would be welcome. Joseph H Allen (jhallen@world.std.com) 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]]);} -- ============================================================================ The above are my own views, not the views of HP Tom Gardner Hewlett Packard Laboratories, Filton Rd, tgg@hpl.hp.com Stoke Gifford, Bristol, Avon, BS34 8QZ, ENGLAND. Fax: +44 117 9228924 Tel: +44 117 92 29 29 1 ============================================================================Article: 12841
In article <F1qvxI.MzK@hplb.hpl.hp.com>, <tggNoSpam@hpl.hp.com> wrote: >How does it compare with the MicroChip PIC devices. My personal suspicion is >that the PIC devices are smaller (probably), cheaper (certainly), faster >(probably), more peripherals such as timers/adc/dac/etc (certainly), >more software support (certainly). They are smaller and cheaper, but they are slow and difficult to program. Although it is true that their simple harvard architecture design gives them 5MHz single cycle (20MHz clock, 4 clocks per cycle) instructions (except for branches), the instruction set is very week and there is basically no comparison between it and TE16 (or any real microprocessor). Keep in mind that PICs: - Can only directly address 32-128 bytes, depending on the model - Require bank switching to directly access the rest of RAM (no more than 256 bytes total). - Have only one indirect address register- all complicated addressing modes require explicit address calculation - Can not access seperate program ROM except through immediate instructions (this is PICs biggest weekness, and is week even by microcontroller standards). - Can not jump to computed addresses (only direct addresses). - 2-8 level subroutine stack. - Subroutines can only exist in certain memory areas because the call insn, has fewer direct address bits than the goto insn. The only thing that's nice about them is their small physical size and low cost. You can get PICs in 8-pin dips, which is pretty cool. Did you now that the PIC architecture is very old? It's been around since before 1979 and was known as the General Instrument 1650 series (not to be confused with GI's CP1600, which was perhaps the first 16-bit microprocessor). My 1981 Osborne 4&8-bit Microprocessor Handbook has a chapter on them. I think they only became really popular when Microchip came out with EPROM versions and Parallax came out with their Basic stamp thingy. The TE16 is one step higher, and is perhaps useful where a more powerful CPU is needed. For example, lots of modems and hard drives still use 6502s. Certainly there are many out of hand software projects due to the 8051 being the wrong choice for a large assembly language program. I think the biggest problem with the TE16 (and all 8-bits) is its limited 64K address range. In fact the TE16 is a cut down version of the 24-bit CPU that I was originally thinking of (think of the exact the same design but all regs are 24-bits- notice that there is space for 24-bit immediate data and direct addresses in the instructions). I did the cut down version because the instruction sequences were getting pretty long and I was really wanting to fit it in the XC5202. Perhaps I'll make the 24-bit version in the future. -- /* 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: 12842
Hello everyone, Thank you very much for your help. I have received a lot of interesting replies to may question, many of them where really usefull. I am going to use some of the ideas in my small design but I am still not sure about the "paralell" slave mode in Xilinx, but it seems that the serial mode is much easier to implement, and I can use the source code from the Xilinx web site for it. If you are interested in the result of this, please send me a note, and I will send you the Gerber file when it is ready. Regards, Farhad A.Article: 12843
It is probably impossible to build a general purpose CPU in an FPGA, such that it is *cheaper* than a standalone CPU. This is simply because an FPGA is a very cost-inefficient way of building logic, compared to a custom LSI, or even compared to an ASIC. However, if you need only something fairly simple, but that something has to run fast, then you have a chance with this design, because a fast standalone CPU is going to be expensive. One could clock a FPGA design at maybe 50MHz, and how much is a 50MHz CPU going to cost? You are probably looking at a fairly expensive DSP. I know you can buy a 40MHz "8051", in fact most modems use those, but how many clocks does an 8051 need to do something? Other cases I can think of are: For an ASIC. This is a really good application, because CPU cores are normally quite expensive. And with external EPROM for the code, you get better design security because disassembly of the code won't get anyone very far. And some of the "best" ASIC vendors don't offer CPU cores at all; I recently did a *very* low power ASIC design and none of the vendors who could do it could offer a CPU core. So you are looking either at a DIY design, or a purchase of a commercial core and those ain't cheap. Also, in an ASIC you can get really high speeds. For minimal PCB space, eliminating a separate CPU chip. This is valid for both an FPGA and an ASIC. For better design security generally. >How does it compare with the MicroChip PIC devices. My personal suspicion is >that the PIC devices are smaller (probably), cheaper (certainly), faster >(probably), more peripherals such as timers/adc/dac/etc (certainly), >more software support (certainly). -- 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: 12844
Large Chip maker company is looking for ASIC designers, EDA SW and HW people in Phoenix, Arizona and Ontario, Canada. We provide work visas if needed. Req: university diploma 2+ years experience Pls. send your TXT only resume to us. Gary Lang Gary N. Lang Vice President of ACD,Inc. E-mail: garynlang@aol.com http://www.acdcon.com/Article: 12845
Replacing the CPU is the first step. The gains come with a slight additional effort to replace peripheral chips. Or adding that special instruction to the CPU that increases speed by a factor of 5. Or using a custom assembly language for security. Processors alone won't do it. They are a required first step. Simon ======================================================= z80@ds1.com (Peter) wrote: > >It is probably impossible to build a general purpose CPU in an FPGA, >such that it is *cheaper* than a standalone CPU. This is simply >because an FPGA is a very cost-inefficient way of building logic, >compared to a custom LSI, or even compared to an ASIC. > >However, if you need only something fairly simple, but that something >has to run fast, then you have a chance with this design, because a >fast standalone CPU is going to be expensive. One could clock a FPGA >design at maybe 50MHz, and how much is a 50MHz CPU going to cost? You >are probably looking at a fairly expensive DSP. > >I know you can buy a 40MHz "8051", in fact most modems use those, but >how many clocks does an 8051 need to do something? > >Other cases I can think of are: > >For an ASIC. This is a really good application, because CPU cores are >normally quite expensive. And with external EPROM for the code, you >get better design security because disassembly of the code won't get >anyone very far. And some of the "best" ASIC vendors don't offer CPU >cores at all; I recently did a *very* low power ASIC design and none >of the vendors who could do it could offer a CPU core. So you are >looking either at a DIY design, or a purchase of a commercial core and >those ain't cheap. Also, in an ASIC you can get really high speeds. > >For minimal PCB space, eliminating a separate CPU chip. This is valid >for both an FPGA and an ASIC. > >For better design security generally. > >>How does it compare with the MicroChip PIC devices. My personal suspicion is >>that the PIC devices are smaller (probably), cheaper (certainly), faster >>(probably), more peripherals such as timers/adc/dac/etc (certainly), >>more software support (certainly). > > >-- >Peter. > >Return address is invalid to help stop junk mail. >E-mail replies to zX80@digiYserve.com but >remove the X and the Y. Design Your Own MicroProcessor(tm) http://www.tefbbs.com/spacetime/index.htmArticle: 12846
With the complexity of systems and SoC accelerating, system-level verification is quickly becoming the bulk of the design effort (many wise sources state that verification has exceeded 50% of total design effort, and we agree). Janick Bergeron, our VP of Technical Wisdom, shares some insight into system-level verification issues in a new Online Seminar in the Qualis Library. This seminar was originally presented at the 1998 Mentor Graphics Users Group (MUG) conference in Portland, Oregon. The abstract has been included below. To attend the Online Seminar, pull up your web browser and jump to: http://www.qualis.com/cgi-bin/qualis/libObject.pl?object=op001 There is no charge to attend this Online Seminar, but you do need to be a registered user of the Qualis Library. Registration is simple and quick. Really. To find out more about the Qualis Library, go to the home page of the Library at http://www.qualis.com/cgi-bin/qualis/library.pl . ONLINE SEMINAR ABSTRACT ----------------------- The elusive "system-level" verification can no longer be considered a nice-to-have activity, only to be done as time allows in the schedule. No design is an island: they have to eventually work within a system and function with other design components. Today's market pressures not only require first-pass success on silicon but first-pass success on the entire system. System-level verification can follow a well defined process to ensure first-time success. System-level verification differs from component or block-level verification in two important aspects: visibility and complexity. The lack of visibility into major components is what defines the "system" level: the design is primarily composed of large blocks of functionality that were engineered elsewhere: chipsets in board designs or IP blocks in ASICs. Complexity is the by-product of the design: the combination of possible states of the system grows exponentially with each additional component. Characteristics of a proven system-level process are presented. They include planning, documentation, impact on design, scheduling, staffing, execution, and management. Issues such as tool requirements, design methodology, and design culture are also addressed. Throughout the presentation, examples from real-life system-level verification accomplishments will be used. -- MichaelArticle: 12847
mench@mench.com writes: > Ad Verschueren <ad@akebono.ics.ele.tue.nl> wrote: > > > Hierarchy and stucture can (someone correct me if i'm wrong :-) > > *only* be represented with entities and components - whereas (the > > more complex) behaviour is captured in processes. Processes are > > 'flat' pieces of procedural code - although they can (and should) be > > structured, that is not the structure we are looking for... > > Actually, you can also use block statements. > > Paul Thanx, I stand corrected. When we created our VHDL generating rulebase, we looked very briefly into the use of blocks for internal structure. We found entities and components a better match for the re-use of RTL entities in our tool. Also, IIRC, the Compass tools we were writing the rulebase for did not support blocks. Grin, another line of followups to the original message also indicates that blocks (if they were supported by more tools) would be much used. Ad -- --(dr.ir.) Ad (A.C.) Verschueren-------------------A.C.Verschueren@ele.tue.nl-- Eindhoven University of Technology -- Information and Communication Systems Smail: Room EH 9.27 ----- P.O. Box 513 ---- 5600 MB Eindhoven, Netherlands Voice: +31-40-2473397 FAX: +31-40-2433066 [corner for rent, apply within]Article: 12848
> Alexander Sherstuk wrote: > > Hi All, > I would appreciate very much, if somebody would share > his experience: > What types of step-down voltage regulators can be used > to convert 5 Volts to 3.3 (2.5) Volts to power XILINX > chips? For prototyping you might use a linear reg (with heatsink!?) - see general electronic parts catalogue. For production the solution would likely want a switching converter for reasonable efficiency & small size. It would likely comprise of at least an 8 pin chip, fast diode, inductor, and some low-esr capacitors. Suggest looking at data-books or design guides from Maxim, Linear Tech, Mitel, National Semiconductors,etc > What are part numbers of the suitable voltage regulators? This will depend on your overall power requirement, and possibly on whether you optimise for efficiency or size. Let me know more & I'll be specific!Article: 12849
************************************************************************ Call for Papers The Seventh Japanese FPGA/PLD Conf. & Exhibit Pacifico Yokohama, Yokohama, JAPAN, July 7 - 9, 1999 ************************************************************************ IMPORTANT DATES: Deadline for submission of abstracts: Feb. 5, 1999 Notification of acceptance: Mar.19, 1999 Deadline for camera-ready papers: May 14, 1999 AIM AND BACKGROUND OF CONFERENCE: The "Japanese FPGA/PLD Design Conference & Exhibit" is a conference and exhibit, which provides a forum to exchange ideas and promote research on the fields of device technology, design technology, EDA support tools, and applications for FPGA/PLD. At the seventh conference and exhibit, we are planning to introduce more practically technical information and leading edge technology trends on "Devices, Designs, EDA tools, and Application for FPGA/PLD"; especially on the FPGA/PLD in the 21st century. To make more intensive discussion possible on the current studies and the sprouting ideas, the next conference will expand the number of papers at the paper presentation session and tutorial sessions. For example subjects handled on these session is such as FPGA/PLD device which enables entirely new functions, developing "System on Chip" using IP, new design methodologies for FPGA/PLD toward the 21st century, and killer applications for FPGA/PLD. We invite papers on the following topics and also welcome papers on related fields, such as system LSI design, development, and application. Papers on case studies of design or application from industries are most welcome. But we do not welcome papers which have the same content, with the paper already published or planed to be published in the near future. In the conference the official language will be Japanese and English. We are looking forward to your papers. AREAS OF INTEREST: Original papers on, but not limited to, the following areas are invited. a) Device architectures b) Circuit design technology c) CAD/DA technology d) Development support technology with FPGA/PLD-compatible IP e) Developing System on Chip using IP or VSI f) Compiler technology for embedded systems g) Emulation technology and rapid prototyping h) Hardware/Software codesign i) Reconfigurable computing j) Usage of FPGA/PLD with embedded core k) Evolving hardwares l) All kinds of application using FPGA/PLD m) Other topics related to FPGA/PLD SUBMISSION OF PAPERS: Please send six (6) copies of extended abstract and the completed application form to the address below. Your papers will be reviewed by the program committee for selection. Besides technical contents, your extended abstract is expected to contain a presentation outline describing the background, goal, approaches, importance, and originality. The extended abstract may not exceed four pages of A4 size papers, including the title, figures, and tables. Abstracts exceeding four pages will not be accepted. Selected papers will have a chance to present there paper in the conference, either by lecture style or poster session style. In addition, all applicants will receive a three-day conference tickets for free. APPLICATION FORM: Fill in the application form with the title of the paper, name of author(s), author(s) affiliation, abstract(about 100 words), and three or less keywords, with the contact address of the corresponding author; name, affiliation, postal code and address, telephone number, FAX number, and E-mail address. We welcome applications by E-mail or postal mail. Ask for application forms(template) to the address below. AWARD: Excellent papers will be awarded based on the decision made by the program committee. The authors of excellent papers will be awarded at the conference, and will be asked to give presentations at the special session. Supplementary prizes will be also provided to the awarded authors respectively. SUBMISSION OF PAPERS: Deadline for submission of abstracts: Feb. 5, 1999 Notification of acceptance: Mar.19, 1999 Deadline for camera-ready papers: May 14, 1999 Send abstract/application forms or inquires to: Hideharu Amano Keio University 3-14-1, Hiyoshi, Yokohama 223-8522, Japan TEL:+81-45-560-1063 FAX:+81-45-560-1064 E-mail:hunga@ics.keio.ac.jp ORGANIZERS/SPONSORS: Organizers: Steering Committee of The Seventh Japanese FPGA/PLD Design Conference & Exhibit Sponsors: Embassy of the United States of America (pending) Semiconductor Industry Association (pending) Distributors Association of Foreign Semiconductors (pending) International Semiconductor Cooperation Center (pending) In Cooperation with: The Institute of Electronics, Information and Communication Engineers of Japan (pending) Information Processing Society of Japan (pending) ---------------------------------------------------------------------- Tetsuo HIRONAKA Faculty of Computer Sciences Tel : +81-82-830-1566 Hiroshima City University Fax : +81-82-830-1792 Hiroshima, 731-31, JAPAN E-mail: hironaka@ce.hiroshima-cu.ac.jp
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