<rjo>
(i am fed up with xc3sprog/urjtag/flashprog/papilioprog)
siruf has quit [Ping timeout: 264 seconds]
siruf has joined #m-labs
aeris_ has quit [Ping timeout: 245 seconds]
aeris_ has joined #m-labs
aeris_ has quit [Ping timeout: 264 seconds]
aeris_ has joined #m-labs
mumptai has quit [Ping timeout: 246 seconds]
kmehall has quit [Ping timeout: 246 seconds]
kmehall has joined #m-labs
mumptai has joined #m-labs
Gurty has quit [Ping timeout: 246 seconds]
aeris_ has quit [Ping timeout: 264 seconds]
fengling has joined #m-labs
aeris_ has joined #m-labs
aeris_ has quit [Ping timeout: 246 seconds]
aeris_ has joined #m-labs
aeris_ has quit [Ping timeout: 246 seconds]
fengling has quit [Ping timeout: 256 seconds]
fengling has joined #m-labs
Gurty has joined #m-labs
aeris_ has joined #m-labs
_florent_ has joined #m-labs
sb0 has joined #m-labs
<_florent_>
hi
<_florent_>
rjo: To investigate and see if your issue is related to a reset signal:
<_florent_>
You can add an external reset to your SoC in addition to pll_lckd and test it
<_florent_>
You can add an external reset to your SoC in addition to pll_lckd and test it
<_florent_>
when bitstream is loaded from flash.
<_florent_>
sorry
<_florent_>
when bitstream is loaded from flash.
<_florent_>
hmm...
<_florent_>
sb0: I'm OK to avoid I/O in fhdl, can you give me advices on how you would have done that?
<sb0>
the verilog.convert function should return the verilog source plus a dictionary filename -> contents for the memory initialization files
<sb0>
I'd define a class to hold those, and the vns (which would be returned at all times, so we can get rid of the return_ns parameter)
<sb0>
also, that class can have its __str__ method overloaded, so we can keep doing print(verilog.convert(module))
<sb0>
and that would print the verilog source, plus every memory initialization file sorted alphabetically by filename
<sb0>
that class can maybe handle the file IO, e.g. have a method write_to_files(verilog_filename) that writes the verilog source plus all meminit files
<sb0>
now there's the question of modifying the fhdl.specials API so that specials can add their memory initialization files...
<sb0>
maybe add the "filename -> contents" dictionary as a 3rd parameter to emit_verilog (after special and ns), and emit_verilog would insert entries into it
<sb0>
though we should probably factor the filename conflict resolution code (instead of having each emit_verilog check for existing entries in the dict)
<sb0>
well we can have a API function new_file(dict, filename, contents) that checks for filename in dict, modifies it if needed, inserts, and returns the final filename
<_florent_>
otherwise, since Memory is the only specials that will need this, how about doing it on verilog.convert:
<_florent_>
- do a loop in specials
<_florent_>
- test if it's a Memory
<_florent_>
- if it's a Memory and init is not None: add a filename-->contents entry in our dictionary
<_florent_>
but that's maybe something you'll find dirty
<_florent_>
For the others points, it seems fine for me
<sb0>
yes, it is dirty
<sb0>
convert should know as little as possible about the specials. in this case, it should just provide a way for them to add files to the output.
<sb0>
they should not even be called "memory initialization" files
<sb0>
"data files" might be ok
<_florent_>
ok thanks, I'll work on that once KC705 runtime is ok
<sb0>
ok. thanks for fixing!
<sb0>
about that class returned by verilog.convert: I think it should not be put in verilog, as other future backends may use it as well
<sb0>
same for the function that adds entries to the data file dictionary
<sb0>
rjo, you like openocd? I've heard mixed opinions about it...
aeris_ has quit [Ping timeout: 264 seconds]
aeris_ has joined #m-labs
<_florent_>
sb0, I'm not well aware of that (or don't remember) but why is URJTAG needed for M1/Mixxeo and XC3SPROG needed for others Xilinx boards (is there hardware incompatibility in USB programmers?)
<_florent_>
and what are the current issues with XC3SPROG or URJTAG? (We can maybe try to fix it before switching to another solution, I would in all case be useful)
<_florent_>
I/it
<sb0>
m1/mixxeo have parallel flash and xc3sprog does not support it afaik
<sb0>
"xc3sprog, flashprog, urjtag, papilioprog etc are island-solutions that suffer from abandonment, limited features and coderot"
<sb0>
whitequark, are you interested in jtag stuff?
<whitequark>
sb0: hmmmm somewhat
<whitequark>
actually, yes.
<whitequark>
i've long been thinking to deep into it digger
aeris_ has quit [Ping timeout: 265 seconds]
aeris_ has joined #m-labs
ccube has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.91.1 [Iceweasel 31.5.0/20150225035911]]
_florent_ has quit [Quit: Leaving]
FabM has joined #m-labs
aeris_ has quit [Ping timeout: 252 seconds]
aeris_ has joined #m-labs
aeris_ has quit [Ping timeout: 256 seconds]
aeris_ has joined #m-labs
aeris_ has quit [Ping timeout: 264 seconds]
aeris_ has joined #m-labs
<GitHub158>
[misoc] enjoy-digital pushed 2 new commits to master: http://git.io/hEcK
<GitHub130>
misoc/master 82fe83a Florent Kermarrec: sdram: raise NotImplementedError if Minicon is used others memories than SDR (not functional for now)
aeris_ has quit [Ping timeout: 264 seconds]
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
_florent_ has joined #m-labs
<ysionneau>
sb0: I updated the flash.sh on the website so that "./flash.sh" flashes everything, instead of having to do "./flash.sh -a"
<ysionneau>
you can pull if you find the change OK
<ysionneau>
hum one sec
<ysionneau>
need to fix the "usage:" message which still states the existence of "-a" option
<sb0>
[florian], do you know how to talk to broadcom gps/bluetooth chips (bcm4752 in this case) over uart?
<ysionneau>
it's OK now for the pull
<sb0>
i have this thing in my tablet, and there is zero documentation. the serial ports for gps/uart are created, but remain silent...
<[florian]>
sb0: nope, I don't think I have access to their doc
<rjo>
_florent_: ha. good idea. that makes all the difference. flashed bitstream, xip-ed bios works when reset after reconfiguration.
<rjo>
sb0: when i scanned through the code openocd seemed to be the only codebase that is actively developped and clean. and the fact that fpga-jtags support in there is nearly non-existing seems to be the perfect start ;)
<rjo>
sb0: and for the few times when i used openocd to work with embedded arm thingies it was pretty good.
<rjo>
sb0: what is bad about it?
<rjo>
but i am not chained to openocd. if there are other better, cleaner jtaggers, come forth!
<_florent_>
rjo, great for the reset! So we just have to adapt our power on reset I think so that it starts correctly after bitstream configuration
<sb0>
rjo, I'm not sure, and maybe it's good. I just know that Michael Walle tried years ago to implement jtag-ocd for lm32 using it, and that didn't work well.
<rjo>
sb0: with s6 and BSCAN? i would be surprised that s6-jtag is even implemented with openocd.
<rjo>
maybe mwalle is the guy for this then.
sb0 has quit [Ping timeout: 250 seconds]
<rjo>
_florent_: but what/where is the underlying problem?
<rjo>
the fact that this happens only with mor1k is a bit weird. i would think that the start up behavior wrt reading from rom is similar for lm32 and mor1k: both will start reading the reset address in one of the first cycles.
<_florent_>
yes that's weird, I don't know exactly what is going on
<_florent_>
you will have to do some iterations I think to found what's the issue
<ysionneau>
humm lm32 is flushing its caches at boot, I don't know how or1k behaves
sb0 has joined #m-labs
<_florent_>
rjo: you should try to add a power on reset to your SoC
<sb0>
ysionneau, how is everything coming along? any code ready for merging into m-labs/artiq?
<rjo>
_florent_: 256 does not work either. checking my code.
SturmFlut has joined #m-labs
<sb0>
rjo, I remember also trying this with the same result as you...
sb0 has left #m-labs ["Leaving"]
sb0 has joined #m-labs
<rjo>
sb0: on papilio_pro or kc705?
<sb0>
kc705 I think
<rjo>
ack. i believe papilio_pro does not exhibit this bug, does it?
sb0 has quit [Read error: Connection reset by peer]
<_florent_>
sb0: for the kc705 issue, it was already here on Feb 16 (I just retested my uip code from Feb 16 with DDR3 and have the same issue)
<rjo>
ha. what a surprise. a 1<<12 cycle por works.
<rjo>
_florent_: do i need to bisect this?
<_florent_>
no :), I was expecting to have it work with a very few power on clock cycles...
<_florent_>
so that's something like 50 us?
<rjo>
55 µs on a 75 MHz sys_clk.
sb0 has joined #m-labs
<rjo>
maybe the ddram needs to wiggle its toes or the flash needs some time to think after having coughed up the bitstream.
<sb0>
_florent_, hmm, I did start the runtime the week of Feb 23 on kc705, and was even able to program the dds...
<rjo>
_florent_: 3.4 µs < t < 55 µs
<sb0>
maybe it's an intermittent bug and the phase of the moon was right that day
<_florent_>
sb0: yes, in fact it seems related to the runtime size
<_florent_>
but I remember having this issue while evaluating lwip, and then switch to internal blockrams to avoid this
<_florent_>
I'll do some litescope on this issue, but I need a little time to do it
_florent_ has quit [Quit: Leaving]
<sb0>
ok. thanks!
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<sb0>
rjo, papilio pro also has the "xc3sprog direct bitstream load + or1k + xip = no bios" bug
<rjo>
but it does not have the "flashed bitstream, or1k, xip = no bios" bug, right?
<rjo>
_florent_: 13 µs < t < 28 µs to be more specific
<sb0>
no, it doesn't. and I haven't seen it on the kc705 either, but maybe Joe did...
nicksydney has joined #m-labs
SturmFlut has quit [Ping timeout: 272 seconds]
gaetan has joined #m-labs
<gaetan>
bonjour les gens
<gaetan>
aimez vous le biodiesel ?
gaetan has quit [Ping timeout: 246 seconds]
<ysionneau>
19:08 < sb0> ysionneau, how is everything coming along? any code ready for merging into m-labs/artiq? < I'm struggling a bit with the conda integration into travis but it's getting there... will be ready for merging very soon
<ysionneau>
19:08 < sb0> ysionneau, how is everything coming along? any code ready for merging into m-labs/artiq? < the parameter bridge is working, but there is a memory leak that I couldn't locate ...