**** BEGIN LOGGING AT Sat Nov 05 02:59:57 2005 Nov 05 06:07:17 hmm... avnet has a spartan-3e devkit for 69$ - but with 26 weeks lead time :( Nov 05 06:07:40 that one is not yet released Nov 05 06:08:00 tough xilinx said Q4/2005 Nov 05 06:10:24 just checked, they now say: The Spartan-3E Starter Kit target availability is December, 2005. but cost there is 149$ + shipping Nov 05 06:11:32 yeah, the avnet kit comes with a S100E and now RAM Nov 05 06:11:43 *no Nov 05 06:12:02 xilinx is probably a better deal Nov 05 06:12:21 yep Nov 05 06:12:56 on import they will also add german VAT Nov 05 06:13:27 mhh, yeah, but that's less than $ <-> EUR :) Nov 05 06:15:50 if you need to start faster You can buy a Spartan-3 Kit + USB IF at digilentinc.com this then also is approx. 150$ Nov 05 06:18:30 mhh, i already have my virtex2 kit with usb, this should be enough for testing Nov 05 06:19:14 Spatan 3 kit uses a Cypress USB controller. Nov 05 06:19:22 this controller does EPP Nov 05 06:19:54 You include an EPP interface in your FPGA design to commuicate over USB Nov 05 06:20:04 does the virtex operate the same way ? Nov 05 06:20:22 epp? Nov 05 06:20:26 like parallel-port? Nov 05 06:20:29 yes Nov 05 06:21:04 though i do not know if it is fully EPP compliant Nov 05 06:21:06 it uses a FT245BM Nov 05 06:21:12 so it's a parallel interface Nov 05 06:21:14 8-bit Nov 05 06:21:19 not sure about the strobe lines Nov 05 06:21:47 then i guess it is different. Nov 05 06:24:19 With the 3E board You do not get the Cypress Code not specs of the USB protocol Nov 05 06:24:28 All you get is a windows DLL Nov 05 06:27:13 well, ie. with the Spartan 3 board - i juts think they use the same for the 3E Nov 05 06:42:56 well, worst case would be to write the cypress code ourself Nov 05 06:44:15 some extra work, and You can not debug with the module digilentinc sells Nov 05 06:45:33 no serial IF accessible Nov 05 10:19:29 hi Nov 05 10:19:39 hey Nov 05 10:19:47 anyone has some experiances with verilog ? Nov 05 10:20:29 mhh, not sure, lennert possibly Nov 05 10:20:43 lennert ? Nov 05 10:20:57 there are no channels on vhdl and verilog out here Nov 05 10:21:26 what do you want to know? Nov 05 10:23:56 I basically wanted to know why that doesn't work: always @(posedge htread or posedge rd) rdone <= ~rdone; Nov 05 10:26:06 do you get a syntax error? or does it fail to synthesize? Nov 05 10:27:50 ERROR:Xst:899 - "ejtag.v" line 57: The logic for does not match a known FF or Latch template. Nov 05 10:27:58 yeah, synthesize failur Nov 05 10:28:07 split it into two statements Nov 05 10:28:20 like what ? Nov 05 10:28:39 always @(posedge hthread) rdone <= ~rdone; Nov 05 10:28:54 well, actually, you have to rethink all of it Nov 05 10:29:06 yeah but then I can't do a always @(posedgle rd) rdone <= ~rdone Nov 05 10:29:13 there has to be a way to map this to a flip-flop Nov 05 10:29:16 because I would be setting rdone at two different places Nov 05 10:29:38 how would u do it in vhdl ? Nov 05 10:30:04 I basically want to do a JTAG controller in verilog Nov 05 10:30:15 make a process sensitive to clk, act on the rising edge of clk, and use htread and rd as clock enables Nov 05 10:31:00 in hdl, everything should be synchronous - otherwise you'll get stuck in a nightmare of timing issues Nov 05 10:32:05 assign ce = (clk & rd)| (clk & htread) Nov 05 10:32:25 then always @(posedge ce) rdone <= ~rdone ? Nov 05 10:34:42 check the xst docs - there should be examples of verliog-templates for all kind of constructs Nov 05 10:35:12 that seams to work Nov 05 10:39:46 if I have that kind of statement: always @(a) for(i = 0; i < 10; i ++) test = ~test; Nov 05 10:39:59 is it everytime a changes state that i <= i++ ? Nov 05 10:40:26 always @(posedge C) begin if (CE) Q <= D; end <- that's what xilinx recommends for a flip-flop with clock enable Nov 05 10:41:01 the if could be "rd | htread" in your case Nov 05 10:42:40 yeah but what if one of the signal comes from outside the FPGA, like an input Nov 05 10:42:52 then you have to synchronize it before Nov 05 10:42:59 with the clk ? Nov 05 10:43:02 yep Nov 05 10:43:06 ok Nov 05 10:43:10 you have to use one clock throughout your design Nov 05 10:43:35 you are familiar to vhdl ? Nov 05 10:43:37 whenever you cross a clock domain (outside -> inside, faster-clock -> slower-clock) you have to synchronize the signals Nov 05 10:43:49 more than with verilog Nov 05 10:44:01 i started a jtag controller design myself a few weeks ago Nov 05 10:44:11 ah really ? Nov 05 10:44:17 basically what is yours gonna do ? Nov 05 10:44:31 shift data to TMS or TDI, and capture TDO Nov 05 10:44:41 ok Nov 05 10:44:46 for a read/write/readwrite Nov 05 10:44:48 ? Nov 05 10:45:12 yeah, it would do that every time, but the host could decide not to care about the read data Nov 05 10:45:50 ok I wanted to design something that could handle EJTAG Nov 05 10:46:05 yeah, i saw your conversation in my backlog Nov 05 10:46:18 do you think it's easy to do ? Nov 05 10:46:40 i had a brief look at the mips docs - ejtag is basically JTAG + the target specific stuff, right? Nov 05 10:46:48 yeah Nov 05 10:47:04 the jtag-shifting is trivial, i believe i got that right Nov 05 10:47:13 yeah Nov 05 10:47:14 my design had a serious flaw in the host-connection Nov 05 10:47:49 what's going to be harder it the target specific stuff - do you want to implement that in hardware? Nov 05 10:47:53 basically EJTAG_DMA_READ === few 2 instructions and 2 ReadWrite with a flag control between Nov 05 10:48:09 well I wanted to put it on a fpga yeah Nov 05 10:48:22 basically I want to use a FTDI chip to be able to read and write fast from USB Nov 05 10:49:25 what simulator do you use ? Modelsim ? Nov 05 10:49:31 yeah Nov 05 10:49:53 you have a nice tutorial ? Nov 05 10:50:02 how did you learn ? Nov 05 10:50:11 unfortunately not - all learning-by-doing Nov 05 10:50:52 mhh, and the documentation that came with modelsim Nov 05 10:51:06 I used a 75Mips microcontroller first to do some ejtag reading/writing Nov 05 10:51:13 it's just 2x faster than the // port of the PC Nov 05 10:51:17 so it's not that interesting Nov 05 10:51:40 hmm... philips lpc parts are capable of bit-banging at ~15mhz Nov 05 10:51:54 are there expensive ? Nov 05 10:52:08 you can buy dev boards from olimex for ~80 euros Nov 05 10:52:23 there's a wide variety, some including usb ports or even ethernet ports Nov 05 10:52:24 where are you from :) talkin in euros ? Nov 05 10:52:29 .de Nov 05 10:52:40 and you're from france Nov 05 10:52:44 right? Nov 05 10:52:46 I have erased the bootloader from my trendnet 411brp+ router and now i need the file to reflash via jtag, where can I get a new cfe file? Nov 05 10:52:48 at least your hostname is Nov 05 10:54:20 yeah Nov 05 10:54:21 http://www.olimex.com/dev/index.html Nov 05 10:54:25 is that the one you're talkin about ? Nov 05 10:54:36 GCMOTTA: Either try downloading a firmware update from the manufacturer and seeing if it is part of the binary OR find a site that specialises in producing third party firmware for that router. Nov 05 10:55:15 key2: yeah Nov 05 10:55:29 where do you see the prices ? Nov 05 10:56:43 The file from trendnet is just the firmware.trx, there is a source code too in the site. Nov 05 10:57:00 mhh, there was a posting of a olimex representative to some mailing-lists Nov 05 10:57:27 GCMOTTA: You'll have to find somebody with the same router and have them dump a copy of the bootloader if so Nov 05 10:57:42 ok Nov 05 10:57:57 if this module costs 80euros, how much costs just the chip ? Nov 05 10:57:59 40Eur ? Nov 05 10:58:16 heh, more like 2-5 in quantities Nov 05 10:58:37 looks like they're even cheaper Nov 05 10:59:04 a german distributor charges 66 euros for a lpc2148 proto board Nov 05 10:59:04 ok Nov 05 10:59:20 key2: url? Nov 05 10:59:31 so you say I could output bits at up to 15Mhz ? Nov 05 10:59:41 by the way, is it a 32bit controller ? Nov 05 10:59:44 Hummm that is what I suspected. The linksys wrt54gs 1.0 version uses the SAME hardware from my router, is the a way to use the linksys one? Nov 05 10:59:59 GCMOTTA: YEAH Nov 05 11:00:05 and stop bothering with your dead modem Nov 05 11:00:06 you can toggle bits at up to 15 mhz, and yes, it's a 32-bit arm7tdmi-s Nov 05 11:00:11 Are you sure it is the same though? Nov 05 11:00:30 It might use the same chips but it is still up to the manufacturer to specify GPIO routing etc... Nov 05 11:00:53 Tiersten: hope that the CFE is not dead Nov 05 11:01:09 then open it, locate the RX, TX and then use a MAX232 to get the prompt to reflash it Nov 05 11:01:28 vmaster: what compiler do you use and how do you program it ? Nov 05 11:01:41 GCMOTTA said previously that the bootloader has been erased so no, that wouldn't work. Nov 05 11:02:12 GCMOTTA: Anyway, your best hope is to find somebody with the same router and get them to dump it. If not then you could try a Linksys WRT54G one which are floating around. Nov 05 11:02:13 ARM is fully supported by the gnu toolchain, and all lpc2xxx devices include a bootloader that supports in-system programming using a serial port Nov 05 11:02:14 Yes the hardware is the same, I think only GPIO dis different Nov 05 11:03:06 but you could get a much higher performance by combining the uC with a cpld that does the serializing in hardware Nov 05 11:04:09 So i need a serial to reprogram a new bootloader? Nov 05 11:04:23 GCMOTTA: sorry, that was for key2 Nov 05 11:04:28 GCMOTTA: No. Different conversation there Nov 05 11:04:50 ok Nov 05 11:05:42 vmaster: do you have one ? Nov 05 11:06:17 i have one with a lpc2294, but i use it only as a target for the ARM debugger i'm working on Nov 05 11:06:22 I will try to find the same router, Thank you guys. Nov 05 11:06:32 np Nov 05 11:08:55 ok Nov 05 11:09:05 so you get the toolchain and you compile for it ? Nov 05 11:09:10 with a gcc ? Nov 05 11:09:42 yep Nov 05 11:09:50 GCMOTTA, np ;) Nov 05 11:10:50 vmaster: so I guess there is a PLL Nov 05 11:11:01 that you put at the max for going up to 60Mhz Nov 05 11:11:03 right ? Nov 05 11:12:54 yeah, it has an on-chip pll Nov 05 11:13:30 and you toggle bits by writing to a pair of Set/Reset registers, that allow you to toggle individual bits Nov 05 11:14:19 vmaster: so you can tell for example that the pin0 of port A is input and the pin1 of portA is output ? Nov 05 11:14:28 or the whole port A has to be input or output Nov 05 11:15:30 " Direction control of individual bits " Separate control of output set and clear " All I/O default to inputs after reset Nov 05 11:15:56 alright Nov 05 11:16:09 of course, the 15mhz is a best-case maximum Nov 05 11:16:51 so If I do a while(1) Pin0 = ~Pin0; I should be able to see Pin0 oscilate at 15Mhz? Nov 05 11:20:00 LPC2106 16/32 bit ARM7TDMI Nov 05 11:20:05 why do they say 16/32 ? Nov 05 11:20:41 ARM supports two instruction sets: the original "ARM" instructions of 32-bit size, and a compressed "Thumb" set with 16-bit instructions Nov 05 11:20:50 but Thumb still operates on 32-bit data Nov 05 11:20:54 ok Nov 05 11:20:57 with a 32-bit PC, 32-bit registers Nov 05 11:21:14 and for example, what's the difference between a 8bit 75Mips microcontroller Nov 05 11:21:32 and that Nov 05 11:21:58 because I tryed to read from JTAG with a 8bit Microcontroller at 75Mips and it's quiet slow Nov 05 11:22:28 So I wonder why it would go faster with this one Nov 05 11:22:44 you can't compare MIPS between multiple architectures Nov 05 11:23:22 MIPS ? Nov 05 11:23:45 The ARM spec supports more than two instruction sets now. Jazelle for one Nov 05 11:23:46 million instructions per second - that's what your "75Mips" was refering to? Nov 05 11:23:58 yeah Nov 05 11:24:08 Tiersten: heh, yeah, Jazelle, Thumb2 and whatnot - but not on ARM7TDMI's Nov 05 11:24:15 Ah. Nope :) Nov 05 11:24:55 key2: Comparing MIPS is pointless because the manufacturer will always state the value for the quickest instruction and that might be NOP... Nov 05 11:25:15 yeah but I looked at the instruction table Nov 05 11:25:21 most of them take one cycle Nov 05 11:25:31 just few of them takes 2 or 3 cycles Nov 05 11:25:43 but for doing a for() loop, it takes lot of instruction Nov 05 11:25:49 while the ARM might only take few Nov 05 11:26:28 key2: what makes the lpc considerably fast at bit-banging is its ability to toggle individual GPIO lines very fast Nov 05 11:26:54 I could try Nov 05 11:27:04 but I dunno if it would be faster than the // port of the PC :) Nov 05 11:27:06 anyway, as i said before: i wouldn't use bit-banging Nov 05 11:28:20 on the other hand, i wouldn't try implementing all of EJTAG in hardware, either Nov 05 11:28:25 what would be the main difference between using the LPT port of the pc for the JTAG and using this ARM with its port connected to the jtag ? Nov 05 11:28:54 you have to use outb/inb instructions on the pc, and those take at least 1us Nov 05 11:29:02 the PC parallel port isn't particularly fast Nov 05 11:29:11 ok Nov 05 11:29:13 that gives you a maximum frequency of <500kHz Nov 05 11:29:35 so if here I set for once 3 pins for output (tms tdi tck) and 1 for input (tdo) Nov 05 11:29:46 can I read really faster than a PC with 3.2Ghz proc ? Nov 05 11:30:02 yes, but i don't know by how much Nov 05 11:30:22 if it's really important to you i can create a small test program and run it on my lpc Nov 05 11:30:57 yeah :) Nov 05 11:31:01 i would love to Nov 05 11:31:13 but it would take you time to connect to the JTAG port of something wouldn't it ? Nov 05 11:31:43 The PC might have a fast CPU but it can't talk to the parallel port particularly fast for the reasons vmaster has mentioned Nov 05 11:34:16 key2: i was thinking about toggling 3 bit in an endless loop, and watching those bit using a logic analyzer - that should give you an idea about how fast this could go Nov 05 11:34:41 yeah Nov 05 11:34:45 would it take you time to do that ? Nov 05 11:34:46 Using JTAG Tools, a PC parallel port and a IXP420 as a target you can reprogram 128KB in 20 minutes Nov 05 11:35:16 ^^^ has experience with same Nov 05 11:35:24 And this is on a 3.2GHz P4. So no, it's not particularly fast and the PC pretty much grinds to a halt when you're doing this since you're bitbanging the parallel port like crazy Nov 05 11:35:45 hahahaha Nov 05 11:36:03 Tiersten: what do you call Bitbang it ? doing Input output input output ? Nov 05 11:36:04 bitbanging a LPT port and killing a P4 Nov 05 11:36:06 or just sending data ? Nov 05 11:36:30 Bitbang = Twiddling the I/O port manually Nov 05 11:36:41 Like a bit banged serial port would be you implementing the UART in software Nov 05 11:37:08 It basically means you have to be careful with timing because you're doing it all in software and if your app isn't paying attention to the port all the time then you might lose data Nov 05 11:37:46 well Jtag is synchronous Nov 05 11:37:50 you have a tck Nov 05 11:38:10 so you don't need to pay attention of what's going on as long as you now when you expect data to come Nov 05 11:39:03 You still can't make the parallel port go that fast Nov 05 11:39:22 A fast EPP parallel port can do about 2MB/s Nov 05 11:39:29 But that's with all 8 data pins Nov 05 11:39:40 So divide that by 8 to get what each pin is toggling at Nov 05 11:40:17 would be the same Nov 05 11:40:22 because you write 8 per 8 Nov 05 11:40:34 yo don't write bit per bit Nov 05 11:40:39 Yes but your uC can do it faster Nov 05 11:40:58 well Nov 05 11:41:21 It takes me 16s to read 64KB from my BCM with the // port of my pc Nov 05 11:41:37 and it takes me about 10s to do the same from my SX 75Mips microcontroller Nov 05 11:41:58 so I wonder if it would be faster with a 32bit arm Nov 05 11:43:52 What scenix is it? Nov 05 11:44:46 microcontroller 75 Mips really inexpensive Nov 05 11:44:55 http://www.parallax.com/detail.asp?product_id=SX48BD Nov 05 11:53:38 key2, vmaster: no, no experience with verilog Nov 05 11:54:08 you simply cannot toggle on two clock edges Nov 05 11:54:23 that wouldn't work in vhdl either (xilinx tools will say "bad synchronous description" or something like that) Nov 05 12:16:58 heh, yeah, seen that more than once :) Nov 05 12:34:20 okay, i got a clock-period of about 70ns, which is roughly 15MHz Nov 05 12:40:18 key2: setting or clearing seems to take 2 cycles - for jtag, you have to change tdi on the falling edge of TCK, that gives you three writes per TCK cycle, or 6 processor cycles per TCK cycle -> up to 10 mhz, excluding the time necessary for loop handling, reading, data processing Nov 05 12:48:20 three write cycles per tck cycle? Nov 05 12:55:22 he told me that his 8-bit scenix microcontroller was only little faster than a pc's parallel port Nov 05 12:55:54 I remembered reading that philips LPC2xxx arm7s can bitbang gpio's at up to 15mhz Nov 05 12:56:49 i tried that on a LPC2294 i have lying around here, and measured a clock-period of ~70ns Nov 05 12:57:08 my pc parallel port can do 867308 writes per second Nov 05 12:57:13 and i need 2 writes per TCK cycle Nov 05 12:57:19 that was for one write to the GPIO set-register, and one to the GPIO-clear register Nov 05 12:57:20 so that's ~430kHz Nov 05 12:58:38 right, that sucks Nov 05 12:58:58 the limiting factor in the pc is just the distance from the cpu to the southbridge Nov 05 12:59:02 yep Nov 05 12:59:24 well, that, and the ioport architecture of the parallel port Nov 05 12:59:42 if it was a memory mapped device, i could imagine it would be faster Nov 05 13:00:32 vmaster: doesn't matter all that much Nov 05 13:03:19 mhh, on all X86s, io port access take 1us - no matter if there's a device or not Nov 05 13:03:23 *accesses Nov 05 13:05:07 uncached memory mapped accesses aren't blazing fast either Nov 05 13:05:22 reading the status word from my e1000 NIC over the pci bus easily takes 4000 cycles Nov 05 13:05:38 the pc architecture just sucks Nov 05 13:05:55 (2.4GHz cpu, so that's 1.6us) Nov 05 13:06:12 The parallel port is a ye olde legacy device on the ISA "bus" in a PC Nov 05 13:06:26 Tiersten: anything on the southbridge is slow.. Nov 05 13:07:01 Tiersten: heck, anything that's not L1/L2 is slow :) Nov 05 13:07:06 heh Nov 05 13:07:19 Next you'll be complaining that anything not in a register is too slow... Nov 05 13:07:25 yup ;) Nov 05 13:07:40 well, me, robert and jamal have been trying to increase linux routing performance Nov 05 13:07:54 it turns out that a p3 900mhz easily out-routes my xeon 2.4ghz because the p3 has MUCH lower i/o latency Nov 05 13:08:08 That's because the NetBurst architecture sucks Nov 05 13:08:10 my xeon gets stuck at 1Mpps, the p3 easily goes to 1.4Mpps and beyond Nov 05 13:08:30 heh, yeah, NetBurst was probably Intel's single worst failure during the last years Nov 05 13:08:33 You get high clockspeed and crap performance per clock Nov 05 13:08:37 vmaster: so did you analyse to see if we could get really faster ? Nov 05 13:08:41 Tiersten: mwah, uncached accesses aren't _that_ slow on netburst, it's more that the chipset is really crap Nov 05 13:08:58 Oh? E7501? Nov 05 13:09:04 anything E75 Nov 05 13:09:11 i have an E7505 which is pretty bad Nov 05 13:09:24 but the serverworks chipsets are really kick-ass Nov 05 13:09:30 Get a P-M board? Nov 05 13:09:39 key2: see above - yes, you could go faster than a parallel port, best case is 10mhz jtag tck - that's without reading, loop handing, data processing Nov 05 13:10:18 Tiersten: i'm overall pretty happy with the dual xeon, but if i ever get something else, i'll go for opteron Nov 05 13:10:45 :) Nov 05 13:10:59 mhh, you'd have to get a radiator during the winter months, without that dual xeon ;) Nov 05 13:11:00 Tiersten: blows the pants off anything intel for routing and firewalling due to the integrated memory controller and consistently faster L2 misses (in terms of ~100 cycles each) Nov 05 13:11:14 vmaster: true :D Nov 05 13:11:34 my heating has been broken for three years or so anyway Nov 05 13:24:29 vmaster: so let's say you need to read 32bit from JTAG, with a for() loop and shifting bits, at what frequency do you think it would be possible to do that ? Nov 05 13:28:44 mhh, you could calculate that, i guess Nov 05 13:29:15 do some loop unrolling, for 1-8 bit at a time Nov 05 13:29:40 shifting is cheap on arms Nov 05 13:30:17 certainly several mhz Nov 05 13:31:20 but i gotta go now... cya Nov 05 13:35:35 just before you leave Nov 05 13:35:42 would you tell me which toolchain you use for the LPC2106 Nov 05 13:35:43 would you tell me which toolchain you use for the LPC2106 Nov 05 13:48:26 i'm using the toolchain from www.denx.de (site is down today...), but you can also use one from gnuarm.com or http://www.codesourcery.com/gnu_toolchains/arm/ Nov 05 13:49:40 ok Nov 05 13:49:44 there are examples in it ? Nov 05 13:49:54 like how to set the PLL Nov 05 13:49:59 how to input output port ? Nov 05 13:50:26 no - the toolchain is generic for all ARM's Nov 05 13:50:43 the olimex site has some examples, iirc Nov 05 13:50:58 yeah but now with gcc Nov 05 13:51:03 with IAR and some other compiler Nov 05 13:51:34 you just write to various memory locations Nov 05 13:51:43 using pointer ? Nov 05 13:51:48 the details are described in the philips datasheets Nov 05 13:51:51 yes Nov 05 13:51:54 ok Nov 05 13:51:58 sounds good Nov 05 13:52:06 and then once you got your a.out Nov 05 13:52:12 you have to upload it to the ARM using jtag ? Nov 05 13:52:34 you can, but there's also a philips utility which does that using the onchip bootloader Nov 05 13:52:38 Read the docs... Nov 05 13:52:50 ok Nov 05 13:53:05 don't need any other specific files ? Nov 05 13:53:52 well, you could see if you find some headers with definitions for the various lpc2xxx peripherals Nov 05 13:54:06 that's what you do ? Nov 05 13:54:46 i wrote some assembler lines, no C Nov 05 13:55:01 and what do they do ? Nov 05 13:55:17 load registers, store register, branch Nov 05 13:55:25 :) Nov 05 13:55:31 that makes it faster ? Nov 05 13:55:44 it gives you closer control Nov 05 13:56:34 PLLCFG=0x23; Nov 05 13:56:40 I guess I have to find the address of PLLCFG Nov 05 13:56:45 in the datasheet Nov 05 13:56:48 yep Nov 05 13:56:55 either that, or you dig out some header files Nov 05 13:57:03 that you find where :) Nov 05 13:57:14 heh, i would search on philip's site Nov 05 13:57:42 as i said, i've only used the lpc as a target for my own debugger, the only own code i've ever run on it was the bit-bang test i did for you Nov 05 13:58:29 ahha Nov 05 13:58:35 you've never used it for anything else ? Nov 05 14:04:31 no Nov 05 14:05:05 i just needed another target to test with - it's a arm7tdmi-s, my other targets are 720t and 920t Nov 05 14:05:28 anyway, i'm half an hour late, cya Nov 05 14:16:48 I just compiled a very little file and it is 124Kb Nov 05 14:16:56 dunno how this thing works :) Nov 05 14:21:58 Tiersten: is there a way to make the file become a .hex ? Nov 05 15:23:19 <[g2]> lennert any clue on the latency across PCI-E ? Nov 05 15:37:22 key2: you can use objcopy to convert files Nov 05 15:52:36 [g2]: no idea. it's better in theory, but in practise, it doesn't matter that much cause pci-e devices do overlapping transfers Nov 05 15:52:57 [g2]: pci-e e1000 does overlapping tx/rx descriptor fetches which makes performance much better Nov 05 16:11:16 <[g2]> lennert pipelining often helps performance Nov 05 16:47:51 vmaster: you use objcopy to convert the .out into .hex ? don't you need the entry point ? Nov 05 16:49:39 key2: entry point of a .hex file is always the first word, i think Nov 05 17:00:21 Can I input/output fast from a normal PCI port ? Nov 05 17:00:42 for bitbanging ? Nov 05 17:05:50 No Nov 05 17:06:14 Tiersten: So I have for example to bufferise then send throu PCI ? Nov 05 17:07:43 1. The PCI bus is fixed at 33/66 MHz 2. There are other things on the bus. 3. You can't extend the bus very far. 4. You'd need a FPGA or a CPU with a PCI interface to talk to the bus properly Nov 05 17:09:43 ok set let's say I have an FPGA connected to the PCI bus Nov 05 17:10:13 then, I guess I have to buffer the data before making them come out ? otherwise it would still be slow if I bitbang Nov 05 17:10:13 ? Nov 05 17:10:42 Yes. You would want to buffer it and then implement some of the JTAG protocol in the FPGA Nov 05 17:11:01 You'd fill a buffer and then tell the JTAG controller you designed into your FPGA to clock it out Nov 05 17:12:15 Tiersten: so let's say I implemented a read/write/readwrite function in the FPGA, then even like that, If I ask the fpga to ReadWrite, it would still be slow if I don't buffer few ReadWrite commands trough the fpga right ? Nov 05 17:12:58 It'll be faster and more efficient that if you were just using an IO port since once you've send the chunk of data to the FPGA, the CPU can go off and do something else Nov 05 22:59:01 anyone there ? **** ENDING LOGGING AT Sun Nov 06 02:59:59 2005