<lekernel>
cde, if you want a safer option, you can flash the bitstream from FN
<lekernel>
then you don't need jtag
<cde>
right
<lekernel>
and potentially M1-frying circuits :-)
<cde>
I was thinking in case I want to flash something entirely different, like a 8-bit softcore CPU on top of the M1 SoC
<lekernel>
be careful it doesn't take 5V
<lekernel>
and JTAG is 2.5V, serial is 3.3V
<lekernel>
you can flash that from FN too
<lekernel>
and reboot in rescue mode
<lekernel>
to flash again
<lekernel>
until your JTAG pod is sorted out
<cde>
cool
<cde>
but what if the Mico32 is no longer present in the bitstream? would it work?
<lekernel>
anyway, I think you'll probably need to start with HDL simulations ...
<lekernel>
there are two bitstreams, the regular one and the rescue one
<cde>
yes, I know :) I'm probably thinking too much ahead
<cde>
aah I see, I must have skipped this when reading the wiki
<lekernel>
if you replace the regular one with any sort of bitstream, you can always boot the rescue one (with LM32) to reflash
<cde>
that is an awesome feature, I probably won't need JTAG at all
<lekernel>
JTAG is faster and also allows you to load the FPGA without writing the flash etc.
<wolfspraul>
cde: did lekernel answer your questions?
<wolfspraul>
for the most part I am unqualified to answer them anyway, and would need to ask lekernel first :-)
<cde>
indeed he did
<wolfspraul>
I'm just the shipping guy who will send you a new jtag-serial daughterboard :-)
<cde>
hey, no worries, I haven't even got past the synthesis and simulation part anyway, I'm very far from reflashing the real hardware :)
<cde>
lekernel_: could it be possible to load the bitstream from the SD card instead of flash ? or to be more precise, what would be the difficulty of implementing it
<lekernel_>
probably quite annoying and I can't really see a clear advantage to it
<cde>
I was thinking, in case the flash becomes damaged
<cde>
it might also be possible to load the bitstream from other inputs, such as the microphone
<cde>
I'm curious to know, how do you perform level shifting on the USB JTAG daughterboard?
<cde>
I guess the Amontec JTAGkey is expensive because of the IO voltage autosensing
<lekernel_>
there is also automatic I/O voltage to some range on the M1 daughterboard, it's just one cheap integrated circuit
<lekernel_>
you can find the kicad schematics of the jtag board there
<cde>
thanks very much
<cde>
do you think the ADV7125 is capable of outputting 1920x1080? (same question for the ADV7181B)
<lekernel_>
the limit is the pixel clock; if you use the low refresh rates like 30Hz or so (compatible with a few LCD monitors) it should work
<lekernel_>
the 7181 is just a low definition PAL/SECAM/NTSC decoder
<cde>
I see
<cde>
I was thinking about hardware video decoding (eg WebM, H.264, ...). do you know the what is the limiting factor (FPU, ...) ?
<lekernel_>
developer time
<lekernel_>
:)
<lekernel_>
at high resolutions it'd probably never correctly on the LM32
<lekernel_>
you'll need quite some HW acceleration, which sounds very feasible
<cde>
if we want to compete with TI's OMAP, or qualcomm stuff we'll need 3D and hw video decoding (possibly encoding as well)
<cde>
maybe I'm being overly ambitious here :)
<cde>
btw what is the status of the fpgatools project as of now? any ETA?
<cde>
brb
<wolfspraul>
lekernel_: any picturs or videos from the lpm event?
<lekernel_>
we should get some on the Belarusian national TV (hopefully including the M1), but I'm not sure when :-)
<lekernel_>
I'll try to grab some others in the meantime
<lekernel_>
but I think the best one so far is the Masala concert
<wpwrak>
lekernel_: btw, what amount of assert/abort would you consider acceptable in the scheduler ? i have a few that catch "impossible" conditions, reference counts going below zero or the arity dropping out of the allowed range. can i leave them in or would you rather have a "nice" exit (return -1) ?
<wpwrak>
(running out of code or registers produces just a return -1)
<wpwrak>
ah, and one thing i'm still curious about: what would happen if an instruction used the same non-zero register as argument an in its destination slot ? would the result be undefined ? or would something useful happen ?
<lekernel_>
iirc it uses the previous register value (before the write) to start the new computation
<lekernel_>
assert/abort on conditions that come from internal software bugs are acceptable
<wolfspraul>
lekernel_: but masala was warsaw, no?
<lekernel_>
wolfspraul, yes
<wolfspraul>
I mean do you have pics or videos from belarus?
<wolfspraul>
did you switch the patches for the masala concert manually?
<wolfspraul>
did you have a plan, or just spontaneous?
<wolfspraul>
how did you switch?
<lekernel_>
wolfspraul, I'll certainly get a few, but they're not as good as those from Masala which, for once, had both a decent camera setup and very motivated dancers :-)
<wpwrak>
lekernel_: (previous register value) kewl. let's see what happens if i use that ... :)
<lekernel_>
I used a MIDI keyboard
<lekernel_>
and set it up a bit before
<lekernel_>
I also had a joystick and slider on the keyboard to change patch parameters live
<wpwrak>
piano concert with m1 sounds interesting :)
<lekernel_>
ah, and I didn't get the slightest M1 bug during both cc-party and LPM, which is great
<lekernel_>
I was using the rc3
<lekernel_>
everything worked nice as expected :)
<wpwrak>
nice ;-)
<lekernel_>
even when I fed the camera signal through 20 meters of XLR microphone cable that was never made for this...
<wpwrak>
how do you control camera gain ? so you have it on the midi keyboard ?
<wpwrak>
s/so/do/
<lekernel_>
nah, F5-8 on USB keyboard
<wpwrak>
by the way, why all those function keys ? makes them hard to remember. function keys so 1980es :)
<wpwrak>
(read/write a reg in the same instruction) hmm, too difficult to tweak the scheduler to do this. would need to add the ability to go back in time a bit. needs a bit more work from the folks at CERN.
<kristianpaul>
may be a dual-ported memory can do the trick?, some from spartan 6 have those features like write-first, read-first
<kristianpaul>
that jtag-serial pod is very likelly to ge hot
<kristianpaul>
s/hot/get heat over time
<wpwrak>
(dual-ported) according to lekernel, the SOC can already do this. it's just that my scheduler doesn't unblock the next writer to register X until the last reader of the previous content of X has been issued. this means that read and write can never overlap.
<wpwrak>
to make them overlap, i would have to schedule the writer N cycles before the last reader runs. this is tricker. the current algorithm only looks ahead, never goes back to change the past.