<nats`>
uhhmm tbh vivado is way above ise, if you want argument we could discuss that in private
<sxpert>
so I'd like to be able to use said minispartan6 with something else at some point ;)
<nats`>
I don't know if there is a known effort on serie 6 maybe ask digshadow
<digshadow>
sxpert: theres definitely interest in 6 series, but nobody working on it
<digshadow>
is that something you might be interested to add support for?
<sxpert>
digshadow: unfortunately, I'm rather unqualified
<digshadow>
sxpert: if you are interested but aren't sure how to start, we can help with that
<nats`>
the idea is not stupid because serie 6 despite being really expensive compared to serie 7 keeps some advantage like static consumption
<sxpert>
(and lack time)
<digshadow>
thats a bigger issue :)
<sxpert>
nats`: the 6 series is in a large number of blackmagic devices
<digshadow>
sxpert: have you used them? how was your experience?
<sxpert>
which are pretty cheap, and could gain from opensource firmware
<nats`>
blackmagic the video manufacturer ? (if the discussion continue we may have to switch to private or an other channel to not pollute chan)
<sxpert>
nats`: yeah
<digshadow>
I think he means the 1bitsquared product
<digshadow>
ah
<digshadow>
nats`: but yeah thanks for keeping OT
<nats`>
is it a good idea to have a linked chan where we could put related but not totally ontopic discussion in case it interest more people in the chan ?
<nats`>
something like symbichat
<nats`>
(I'm not fan of having tens of channel but may be useful here)
<digshadow>
well theres ##openfpga
<nats`>
ah sure :)
<digshadow>
which tends to be looser
<nats`>
get it :)
<sxpert>
noted
<nats`>
I'll add it to my chan list again, if you want to keep going on the discussion sxpert ping me there :)
<nats`>
digshadow, Bug #501
<nats`>
are you talking about the output of get_pips ?
<nats`>
if yes I tried to do that because 072 relies on it but a simple puts seems not enough each item of pips is stored with a string and it seems that's not good
<digshadow>
nats`: I think someone is working on that
<digshadow>
already
<digshadow>
marked as assigned
<nats`>
oky so I'll wait to integrate it in 072 because i didn't manage to do that well
<digshadow>
unless kgugala wants to hand off to you?
<digshadow>
ah? its used there as well?
<nats`>
in 072 yes
<nats`>
and I call it a lot of time now
<nats`>
in each job
<nats`>
but beware get_pips with no -ob_object return something like 2e6 results on the 50T
<digshadow>
gotcha. So making it common would speed that up quite a bit
<nats`>
yep
<nats`>
that's why I tried
<nats`>
but failed :D
<digshadow>
nats`: just talked to him
<digshadow>
sounds like you should be good to take that
<digshadow>
hes mostly working on 052
<nats`>
ohhh if he wants to do that no problem !
<nats`>
I don't want to take it from him
<digshadow>
no, I think you should go for it
<nats`>
oky
<digshadow>
hes focusing on the core logic of 052, not list pips
<nats`>
so the idea is to find a way to store that
<nats`>
it could be binary or text ?
<digshadow>
it should be the same file format as it is now right? just only generated once
<nats`>
are we talking about the same things, the output of get_pips command ?
<nats`>
it's not a little overkill for a "run once" script ?
<nats`>
I'm looking it I'm not sure it's usefull to go into such complexity
<mithro>
If you want to chat about alternative firmware for Blackmagic products I recommend joining #timvideos channel
<nats`>
sure but I was more discussing making an opensource board :)
<litghost>
If you want to avoid complexity, then avoid introducing threading to being with. If you want parallel execution, multiprocessing.Pool is the safe and recommended way to do it
citypw has quit [Remote host closed the connection]
<nats`>
litghost what's your opinion ? I think I should modify the way I call thread and calculate the index
<nats`>
oky I'll rewrite it
<nats`>
but for what I saw the current version is working well at catching signal
<litghost>
The code will actually get simplier using Pool, because it will handle the nbParBlock logic for you
<nats`>
I have to read about that I really don't know those module it's literally 10 years I didn't write real python code :)
<litghost>
If should just be #1 create pool, #2 start worker, #3 add work, #4 get results (or handle error) , #5 close pool
<litghost>
Opps, #2 start workers isn't required, creating the pool starts the workers
<somlo>
after building the latest yosys, prjtrellis, and nextpnr, I successfully managed to compile one of the examples included with prjtrellis (soc_versa5g); But after connecting the LFE5UM5G-45F-VERSA-EVN board via usb, and running "make prog", I get an error from openocd (https://pastebin.com/udAHnXFQ). The board stops blinking and spinning its segment-LED thingie, so *something* happens, but not quite what *should* happen. Any clue as to what I'm
<somlo>
screwing up (I'm a n00b at openocd and jtag) much much appreciated!
<daveshah>
somlo: you need to set J50 to bypass the ispclock
<daveshah>
short (1, 2) and (3, 5)
* somlo
digs around for magnifying glass...
<daveshah>
for some reason openocd can't cope with the ispclock in the JTAG chain, even if you give it the IR length and other details
<somlo>
3,5 --that would be the two upper-left-horizontal ones and the far-right vertical two (in a ":::" pattern) -- right ?
<somlo>
I had (1,2) (3,4) and (5,6) from the factory
<daveshah>
yes
<somlo>
I get the same behavior
<daveshah>
same error too?
<daveshah>
would you be able to post a photo of your jumpers?
<somlo>
daveshah: same error, same numbers (except for at the bottom, where I get different READ values each time
<somlo>
daveshah: I'll upload a picture in a few minutes -- and thanks a ton for your help !!!
<daveshah>
one more thing to try would be to put the CFG0, CFG1 and CFG2 jumpers all up (off)
<nats`>
litghost, I still have to make a loop to create pool of 4 thread no ?
<somlo>
there's four dip switches (4,3,2,1) with (3,2,1) labeled cfg0, 1, and 2, respectively
<somlo>
and they're down,down,up,down
<daveshah>
somlo: yeah, try all four up
<daveshah>
that forces it to JTAG mode, which shouldn't be necessary but might be for some odd reason
<nats`>
ahh no if I understand correctly you tell the pool to create 4 worker and feed the data and it'll do whatever needed to process all the data while using only 4 parallel thread
<nats`>
?
<somlo>
now I don't get the blinky default behavior on power-up, and still the same error
<daveshah>
somlo: actually I think your versa board might be from the bad batch
<litghost>
nats: No, create the pool of 4 once. Then add all of the work at once (either via map/map_async/imap/imap_unordered). Once all the work is added, it will be batched to each worker.
<daveshah>
what is the text in the top right corner, and what is the text on the FPGA?
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<daveshah>
somlo: yes, you have a bad versa
<daveshah>
Lattice accidently built a batch of Versa 5Gs with non 5G FPGAs
<daveshah>
This is the second I've seen now
<daveshah>
somlo: replace the nextpnr command in the Makefile with `nextpnr-ecp5 --json attosoc.json --lpf versa.lpf --basecfg ../../misc/basecfgs/empty_lfe5um-45f.config --textcfg $@ --um-45k --freq 50 --speed 8` and try again
<somlo>
so basically s/um5g/um/g :)
<sorear>
isn't the non-5G architecturally the same whenever both meet timing?
<sorear>
I guess, they have different IDCODEs in OTP and that confuses openocd?
<somlo>
hehe, if anyone anywhere ever makes a bad batch of anything, I will probably end up with it :D
<daveshah>
sorear: yes, the idcode is in the bitstream too
<daveshah>
Timing is complicated here, because the 5G version runs at higher Vcc which accounts for the faster fabric
<somlo>
wonder if I can get them to send me a replacement...
<daveshah>
I guess this board runs the non 5G version at the higher Vcc, so timing is anyone's guess, although probably closer to the 5G
<daveshah>
somlo: yes, I'm sure you can
<daveshah>
However, there's a risk of getting another from the same batch if you go through the distributor
<sorear>
general semiconductor process question: how correlated are process variations on nearby transistors? on a "slow" chip, are all of the transistors slow, or just a few of them?
<sorear>
I guess there must be some correlated variation since I've seen in-circuit measurement devices that rely on being "near" the operational circuit, but a spatial power spectrum would be very interesting here
<somlo>
daveshah: thanks again, make prog now doesn't error out anymore, and I get 8 flashing LEDs next to the usb connector, four red, and for yellow
<daveshah>
Connect to the second uart (ttyUSB1 with no other devices) at 9600 and you should see hello world
<somlo>
whoo hoo, it works! thanks again for the handholding!
<daveshah>
\o/
<nats`>
litghost, I wrote that but I'm sure it's good enough to handle a crash in one of the thread
<nats`>
can you explain to me how it'll be handled ?
<nats`>
because in case of crash of one it should stop all other
<litghost>
the pool context manager should call terminate
<nats`>
oky
<nats`>
I need to fix the fact that map can't take multiple argument
<somlo>
while I'm on the topic of ECP5 dev boards, is there anything out there with e.g. a LFE5UM5G-85F and at least 128MB of DDR RAM (i.e. something comparable to the nexys4-ddr or Arty)?
<daveshah>
Not at the moment
<daveshah>
The only board with significant DDR is the Versa
<somlo>
If only they made an 85 kCell version...
<sorear>
any guesses why they didn't?
<litghost>
just send an list of arguments
<nats`>
you'll certainly laugh but I don't know how to construct it right :p