Skip to main content
Topic: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Timing (Read 161121 times) previous topic - next topic

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #45
[quote author="rsdio"]I'm assuming that dogsbody can handle accessing the extra 2 bits of the BRAM in the FPGA as Jack was planning.  This seems like a good way to get the maximum use out of the FPGA, and might even simplify things by placing the RLE flag in a consistent location.  There's even the potential for a 2nd flag, although I can't imagine a use for that just yet.[/quote]
Absolutely.  There are 4 extra bits available (we've a 6k x 36 bit RAM to play with).  So we -could- have 256 counts per 8 bit sample (8 bits + rle-flag), 128k counts per 16 bit sample (16 bits + 1 extra + rle-flag), and 32 Gsamples per 32 bit rle count (32 bits + 3 extra + rle-flag).    Over five minutes of non-changing captures per 32-bit word at 100Mhz!!  Weeks for 6k samples!!

The upload bitstream would change though.  Simple is probably best.  Something like:   

8-bit:  <value><rle-count>
16-bit:  <value-b0><value-b1><rle-count0><rle-count1><rle-count2>
32-bit:  <value-b0><value-b1><value-b2><value-b3><rle-count0><count1><count2><count3><count4>

[ -- edit:  just realized my rle-count sizes were off for 16-bit & 32-bit -- ]

All samples would have counts following.  Very doable.
-- IED
-- debugging hardware at 2am is a bad idea...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #46
Quote
The upload bitstream would change though. Simple is probably best. Something like:

8-bit: <value><rle-count>
16-bit: <value-b0><value-b1><rle-countlo><rle-counthi>
32-bit: <value-b0><value-b1><value-b2><value-b3><rle-countlo><rle-counthi>

All samples would have counts following. Very doable.

I was just struggling with this very issue, thank you for bringing it up rsdio. Before dogsbody posted his code I had the rle bit setup to roll along with the rest of the memory and had everything routed to the necessary modules. It gave me pause once I realized that the only good way to do this was to add another RLE byte. I was planning on coordinating with Jawi to make it happen when dogsbody came out of nowhere with this awesome contribution!

I like the idea of making the serial bitstream longer, it seems more elegant. But I think we should play it safe and go with additional RLE bytes like dogsbody outlined. Keep in mind that I intend to develop a wireless Wifi option and I don't want to take any chances that the Wifi module will not support anything other than 8N1 communications. I don't think we will notice the extra bytes very much anyways and they are not time critical so the worst thing that will happen is having to wait a little longer for a capture.

Jack.

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #47
[quote author="jack.gassett"]I don't want to take any chances that the Wifi module will not support anything other than 8N1 communications.[/quote]
Exactly my thinking.  I don't think rxtx libraries are guaranteed of being graceful either for non-8N1.

We can compensate for overhead (a little) by tweaking the SPI uplink between fpga & pic.  There is a lot of dead time between bytes.    In response to "dataready", the PIC writes 0x7F to the fpga, which supplies the SCLK pulses the fpga needs to upload data.    The PIC asserts CS, pulses SCLK, deasserts CS, repeats...

If the PIC could handle it, my image can happily output much longer bursts.    If the PIC wrote 64 non-stop 0x7F's (no CS gaps) uploads would be much faster.
-- IED
-- debugging hardware at 2am is a bad idea...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #48
Quote
If the PIC could handle it, my image can happily output much longer bursts. If the PIC wrote 64 non-stop 0x7F's (no CS gaps) uploads would be much faster.

It should be doing that now.

Code: [Select]
			//give preference to bulk transfers from the FPGA to the USB for best speed
if((PIN_FPGA_DATAREADY==1)){//test for bytes to send from FPGA to USB
if((uartincnt<USB_OUT_BUF)){//test for free buffer space
//get SPI to buf
PIN_FPGA_CS=0;
PIN_LED=1;

//continue to fill the USB output buffer while
// there's free space and the data pin is high
while( (PIN_FPGA_DATAREADY==1) && (uartincnt<USB_OUT_BUF) ){
//FPGA buffer is NOT bidirectional! This does not work (yet)
//if we have data waiting to go, send it with this read
//if(usbbufgetbyte(&inbuf)==0){
// inbuf=0x7f; //send no command to FPGA
//}

buf[uartincnt] = spi(0x7f); //spi(inbuf);
++uartincnt;
Nop(); //if the FPGA needs time to raise/lower the read flag, need to see a logic capture to be sure
Nop();
}

PIN_LED=0;
PIN_FPGA_CS=1;
}//end buffer check

}else{

It is supposed to loop as long as the dataready flag is high and there is room in the USB buffer (up to 64 bytes).

I can connect a logic analyzer and see what is going on.
Got a question? Please ask in the forum for the fastest answers.

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #49
I'm going off what I remember when debugging the SPI issue, and capturing query ID reads on my scope.  My PIC was running the older firmware at the time (OLSv1_firmware_v2.1).  Maybe it was changed for 2.3?
-- IED
-- debugging hardware at 2am is a bad idea...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #50
The loop was a define in v2.1, but we have used it as the default since v2 at least.

These captures show v2.1 and v2.3, they both seem to keep CS high for the entire ID command (doesn't say anything about the data though):
viewtopic.php?f=23&t=1711&start=15#p16560

Will your new SPI module handle higher speeds? I think in the past we had to run the PIC SPI at a fairly low speed or we had problems. Is the 0x7F also needed anymore? I recall it was required in the VHDL version or it wouldn't spit out data.
Got a question? Please ask in the forum for the fastest answers.

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #51
Hmmm...  My memory must be mush from working late.  I clearly remember big gaps between the bursts of SCLK pulses & could have sworn CS was deasserting. 

As for higher speeds, the fpga should handle no problem.  I'd say up to 10Mhz easy (3X).  The 0x7F is needed  though.  The fpga's spi_receiver doesn't care about transmit data, so if it sees CS & SCLK, it grabs bits.  The 0x7F NOP's it.  If you output zeros, you'd reset the fpga. 

If you want to avoid 0x7F's, we'd need a separate CS to enable transmit.  Wouldn't really be SPI, but who cares?
-- IED
-- debugging hardware at 2am is a bad idea...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #52
There's no reason to avoid 0x7F. I didn't know that the FPGA did anything with the data that is clocked in while the dataready flag is high, that makes sense. In the beginning I did some tests to see if it was truly bi-directional (try to get a second 1ALS by sending a second 0x02 while the first 1als is being clocked out), but it didn't work (not that it needs to or should, I just like to poke at things).
Got a question? Please ask in the forum for the fastest answers.

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #53
Sounds right.  Once the spi_transmitter gets busy it ignores query commands.  However, the fpga -is- bidirectional & processes commands.  So you can write regs & change things no problem.
-- IED
-- debugging hardware at 2am is a bad idea...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #54
Just discovered what I think is the cause of RLE issues... 

My Xilinx XISE environment had the -5 speed grade Sparten 3E selected (the high performance flavor).  How that happened I've no clue.  With the -4 grade timing I needed to change clock constraints back to 100Mhz from 105Mhz (oh well).  Compiles clean with no timing violations & RLE appears to work fine now.

Still don't have meta data enabled, since OLS 0.9.2 doesn't like it.    New release4 fpga image is available in the first post of this thread.  Anyway, enjoy!
-- IED
-- debugging hardware at 2am is a bad idea...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #55
@dogsbody: I'll do a quick test with release 4, and then make a beta of 0.9.3 which should work a lot better with both the RLE and metadata commands... I'll keep you posted.

edit: I've uploaded a beta of the 0.9.3 release for everybody interested, see the client topic for the download link(s)...
when good software is not an alternative...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #56
I have upgraded my ols to the new ver4 and thought i would use it  to debug a Playstation2 game controller to usb converter i built with a pic 18f4550.(I know i could buy one real cheap but i have some spare pic's and i learn more if i build things myself ).

Found the problem i was having and the controller is now functioning in windows,The Pic code (asm) i use  for the controller is software spi with a 9 byte packet LSB.

configuration is 
         0x01 0x43 0x00 0x01 0x00 0x00 0x00 0x00 0x00
          0x01 0x44 0x00 0x01 0x03 0x00 0x00 0x00 0x00

it then just loops sending 0x01 0x42 0x00 0x00 0x00 0x00 0x00 0x00 0x00 to "read" the controller.
If i do a capture without RLE and trigger on c/s low i can get the first 2 packets as seen here.
[attachment=1]
It is possible to see "read" packets if i just do a random capture with no trigger, but I was trying to see a few more packets from the start so i thought i could use the RLE and trigger on c/s low , but i can not seem to get a good outcome
as seen here.
[attachment=0]
I have tried various settings to no avail and do not know if there is something wrong with the RLE ,or if i am missing some vital point as to its use.Can anyone give me some advice?
 
I am using the FPGA ver4 and OLS ver0.9.2 (Can not seem to get 0.9.3 working yet).

Nick

P.S To Dogsbody & Jack sorry i left the conversation abruptly the other night but my modem seems to have developed a heat related fault and only works for short periods.

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #57
Looks like the scramble I saw on release3.  Targeting the wrong device created timing violations in the rle module, that messed it up.  Release 4 seems clean though.

If you capture with just RLE & no trigger, does that work?    Is it only the combination?
-- IED
-- debugging hardware at 2am is a bad idea...

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #58
Sorry should have said it is not the combination of RLE & trigger  only happens when RLE is on ,triggered or not.

Re: FPGA Verilog Port + AdvTriggers + Meta + RLE + Timing Fi

Reply #59
In OLS 0.9.2 I'm seeing garbage also.  However...

I've written a test program to capture the output from the FPGA.  The data capture looks completely clean, on all rle settings.  Exactly what I expect, formatted as specified.  Values, rle-count (inclusive of the value), then another value (even if same as last value), followed by another rle-count, etc...

So...  either I'm formatting RLE count values totally wrong, or Jawi has a bit of work left.
-- IED
-- debugging hardware at 2am is a bad idea...