| Products > Test Equipment |
| Upgrading DSLogic Basic to Plus without EEPROM modification |
| << < (10/21) > >> |
| Mrkvak:
Are you able to verify it actually works above 100MHz? I've just changed the source code of DSView: libsigrok4DSL/hardware/DSL/dsl.h, added | (1 << DSL_BUFFER200x8) | (1 << DSL_BUFFER400x4), after (1 << DSL_BUFFER100x16) and changed samplerates100 to samplerates400 in DSLogic U2B definition (around line 532). Now it seems to work up to 400MHz with 64MB buffer, but I have no way of verifying that since I don't have a working generator above 100MHz. |
| RoGeorge:
Use the generator at 100 MHz, and should see about 4 samples for each period of signal. |
| Mrkvak:
Well, it shows 40 samples for 10MHz signal. So I guess this part works - however, the question is whether it will really work at 400MHz or if it'll do just some weird interpolation or something like that. I have my doubts about DSL (whichever version) working reliably with 100MHz+ signal anyways... |
| DrTune:
My experiences: a) Bought U2 Basic. b) Opened it up, wires pin 4 to 7 on the SPI flash c) Reflashed with the "Basic" hex using the modified fx2lafw_eeprom_loader_u2b.exe - replugged, works (with current latest DSView 1.0.1) recognized as Basic model that does 400Mhz (appears to work fine, but obviously no real buffer memory) d) Replaced SDRam with 48LC16M16A2-75 (hot air and microscope. I think I did it ok, we shall see..) e) Booted again (still as 'Basic'), still works (as it's ignoring the SDRam) f) Flashed this "Basic" version with https://raw.githubusercontent.com/podonoghue/LogicAnalyser/master/Software/fx2lafw_eeprom_loader/bin/DsLogicPro hex file using the 'unmodified' fx2lafw_eeprom_loader.exe g) DSView 1.0.1 recognizs it as DSLogic Plus, but hangs ("waiting for trigger") when capture starts h) DSView 0.9.9 does work: Streaming mode: works but oddly I see periodic one-sample zero glitches (e.g. every 16 samples are zero) on all channels. Self-test doesn't even work right. Ack. Stuff is all half-broken, lots of bad samples and stuff. Dammit. i) Put board back under microscope and redid the SDRam soldering, it wasn't a great job the first time j) Plug it back in and... lots of it works! (on V0.9.9) I fed in a 25mhz clock to the first four channels and sampled it at 400mhz (buffered mode) and it's fine! e.g. j1) Buffered mode, 4 channel, 400mhz sampling, with 167.77ms buffer (max available; not using RLE) == 400M*0.5*0.167 = 32MBytes = 256MBit. The data (25mhz clock on all channels) looks great. Adjustable input voltage threshold is working too. j2) NOTE: RLE modes do _not_ seem to work reliably for me at >100Mhz speeds: 8 CH @ 100mhz, 200ms RLE sampling works ok, but stepping same thing to 200mhz gets me garbled results, channels shifted around, general half-crap. However, if I do the same 8CH/200mhz buffered without RLE, the data (superficially) looks good. So.. almost fully working... The RLE crapping out at 200Mhz and up may imply sporadic SDRam errors (that are perhaps returning a few wrong samples not visible to the eye in non-RLE mode; obvs errors in RLE would cause large ripple effects on the data, like what I'm seeing) This may well be memory access time problems (I am using a -75 chip). I may swap the SDRam for a faster one, or just not use RLE modes on this and treat it with a bit of suspicion over 100mhz. V1.0.1. note: You can (kinda) use this with 1.0.1 software too - you just have to use the bitstreams from 0.9.9 (as pointed out on here); in the "DSView/res" folder you can replace the "DSLogicPlus.bin" xilinx bitstream file with the one from 0.9.9 (Note that the firmware is only loaded if the device has not been programmed since it was plugged in, so you can (for example) run v0.9.9, do a capture, then quit and run V1.0.1) I assume the 1.0.1 bitstream is superior, but it hangs on start on a hacked unit. Pehaps my RLE errors are actually something they fixed in the new bitstream.. ? More likely they are that my SDRam is too slow. We shall see... |
| thm_w:
--- Quote from: Crazy_Fox on January 02, 2020, 01:13:05 pm ---Got the crappy DSLogic U2Basic There are at least absent PCB trace from FPGA to RAM chip, so according to the MT48LC16M16A2 datasheet A12 pin (last pin of address bus) is not connected, so at least 16x16 DRAMs cannot be addressed fully. Seems we can add some wire with the same length as another traces for address bus, but I'm not sure that this is the only change in the PCB design. --- End quote --- Thanks, this seems to be working well. Made a small attempt at trace length matching. edit: the 1.0.1 bitstream is working as well. |
| Navigation |
| Message Index |
| Next page |
| Previous page |