<adamw_>
i've still not decided to use which one. but I'd prefer to pick up SOT23-3 package, it's quite hard now to pick a suitable open-drain with SOT23-3 with specified delay time said over 140ms.
<adamw_>
I am still finding..if you have new idea, u can just tell me. ;-)
<lekernel>
mwalle: where did you see those div/mod opcodes?
<Fallenou>
lekernel: to mount a nfs FS from flickernoise shell, is the command mount -t nfs 192.168.0.X:/path /nfs ?
<Fallenou>
with a previous mkdir /nfs
<Fallenou>
?
<lekernel>
yes
<Fallenou>
ok
<Fallenou>
i have a pool error in qemu :x
<Fallenou>
and system hangs
<Fallenou>
an assert fails
<Fallenou>
il rtems code
<Fallenou>
in*
<Fallenou>
when trying to mount a nfs
<Fallenou>
have you ever had this error ?
<lekernel>
Fallenou: no
<lekernel>
adamw_: use whatever package, I don't mind if it's not SOT23... or would a bigger package cause PCB layout problems?
<lekernel>
fyi I have already used the MAX6303, but it's 8-SOIC
<adamw_>
lekernel, the part shows up Non-stocked or  Factory Stock Available on Mouser, I won't pick up.
<adamw_>
ha...good.
<lekernel>
well, I also don't know if the MAX6303 characteristics are good for us
<lekernel>
so you should connect the reset IC to PROGRAM_B and put the diode the other way around
<adamw_>
wrong direction of diode?
<lekernel>
also, this is directly max6303 compatible (no need for open drain), since nothing else drives PROGRAM_B
<lekernel>
yeah, and wrong position of the reset IC if you put it on RP#
<adamw_>
right, nothing drives PROGRAM_B.
<adamw_>
no no..I located reset ic on PROGRAM_B.
<adamw_>
then reset ic's output goes to PROGRAM_B.
<lekernel>
ok. then you should connect the cathode of the diode to PROGRAM_B and anode on RP#
<lekernel>
so the diode is conductive when V(PROGRAM_B) < V(RP#)
<lekernel>
i.e. pull RP# low when PROGRAM_B is low
<adamw_>
anode is positive terminal, cathode is negative terminal.
<adamw_>
your connection will let fpga to reconfigure again when whatever RP# pulls low then high(assert RESET condition)
<adamw_>
is that right?
<adamw_>
but my idea is to let RP# pin got low when power up and delay 200ms at low level then high, also when RP# get low from fpga asserting reset.
<adamw_>
so your connection I confused. ;-) I was thought my connection is right since I've not soldered that diode.
<adamw_>
Shall we need to reconfigure fpga (from PROGRAM_B) whenever asserting NOR flash reset? I was thought they are different operation. :-)
<lekernel>
adamw_: no, we shall NOT reconfigure fpga (from PROGRAM_B) whenever asserting NOR flash reset
<lekernel>
so the diode's cathode must connect to PROGRAM_B
<lekernel>
it's an active low signal!
<lekernel>
during normal operation, PROGRAM_B is at 3.3V
<lekernel>
and RP# can be at either 0V or 3.3V
<lekernel>
when it's at 0V we have
<lekernel>
the diode's cathode (PROGRAM_B) at 3.3V and the diode's anode (RP#) at 0V
<lekernel>
therefore, the diode is blocked, current does not flow through it, and nothing happens
<lekernel>
which is what we want :)
<lekernel>
on the other hand, during reset, we have PROGRAM_B pulled low at 0V by the reset IC, and RP# floating at 3.3V
<lekernel>
then, the diode has its cathode (PROGRAM_B) at 0V and its anode (RP#) at 3.3V
<lekernel>
therefore it becomes conductive and pulls RP# low, which is, again, what we want
<lekernel>
is that clear now?
<adamw_>
hmm...you are totally right! I was wrong. hehe..:-)
<adamw_>
so during activation of reset ic, RP# floating until finishing configuration. right?
<adamw_>
right right
<lekernel>
during the activation of the reset IC, RP# isn't floating, it's pulled low by the diode
<adamw_>
yes, it connected inside fpga is floating, right?
<adamw_>
i think so.
<lekernel>
ah, you mean inside the FPGA? yes
<adamw_>
yeah..inside fpga, i think so.
<lekernel>
before configuration the FPGA doesn't drive RP#, only with a weak pull-up
<lekernel>
after configuration it totally depends on the bitstream
<lekernel>
i'll make that pin open drain
<adamw_>
i tried to find if there's some description on those behaviour like (weak pull-up) inside fpga in document, do you know which doc Xilinx describes?
<lekernel>
maybe spartan 6 user guide... look for information about "hot swapping"
<adamw_>
yeah...remember to let it be as open drain pin after configuration. tks.
<adamw_>
hm..ok
<lekernel>
iirc this behaviour is controlled by the HSWAP_EN pin and it's enabled on the MM1
<lekernel>
but in all cases, the FPGA shouldn't drive pins before configuration
<lekernel>
you actually see the weak pull up on the LEDs btw
<lekernel>
they are dimly lit when the FPGA isn't configured
<adamw_>
this sequence if I can know the behaviour behind those sequences then study the electrical behaviour should be good to understand whole process of configuration.
<Fallenou>
you may find some interesting stuff page 66 of Spartan 6 FPGA Configuration user guide
<adamw_>
Fallenou, hi yes, just seeing it about HSWAPEN. :-)
<Fallenou>
hi :)
<adamw_>
Fallenou, hmm...page 67 shows Floating signal levels are problematic in CMOS logic systems.
<adamw_>
well...i need to read more carefully on this mention.
<lekernel>
adamw_: yes, that's why there are those pull up resistors
<lekernel>
so the signals aren't floating
<lekernel>
wolfspraul: we can go to the photography studio, but it's in Köln
<lekernel>
I was there last month... bad timing :(
<wolfspraul>
saw it, on my list. I will try a new studio we found in Shanghai too.
<lekernel>
saw it? well, I didn't know the location
<lekernel>
but he just answered this morning
<lekernel>
if I can get a chance i'd like to meet him as well, he shoots interesting places as well (particle accelerators, neutrino detectors and the like)
<lekernel>
if this can wait a bit I'll go there in early May
<lekernel>
though the LM8 licensing is unclear (last time I checked)
<lekernel>
http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm says "The LatticeMico8 is licensed under a new open intellectual property (IP) core license, the first such license offered by any FPGA supplier. The main benefits of using open source IP are greater flexibility, improved portability, and no cost. This new agreement provides all the benefits of standard open source and allows users to
<lekernel>
mix proprietary designs with the open source core."
<lekernel>
I contacted Lattice a while ago about this, and they said "we will resolve this"... but they didn't
<Fallenou>
=(
<lekernel>
well, anyway, LM8 wouldn't make a nice LLHDL demo, the code is full of generate statements and old verilog-95 syntax that would be a pain in the ass to implement
<larsc>
lekernel: do you see any problems with using LLHDL as a basis for a simulator?
<kristianpaul>
lekernel: i tought you already tested llhdl with navre?..
<lekernel>
there are already good simulators, why yet another one?
<kristianpaul>
agree
<larsc>
to learn how to write one
<lekernel>
well, indeed a LLHDL simulator wouldn't be very hard to write
<lekernel>
but I was rather thinking of generating back Verilog models of LLHDL code so I could simply use off the shelf tools for this purpose
<kristianpaul>
larsc: very good point ;-)
<lekernel>
which also enables me to use formal verification tools that take Verilog as input, in case of difficult to track LLHDL bugs
<kristianpaul>
i guess is too soon to ask, but what are/will the main diferences between verilog and llhdl?
<lekernel>
as the name says, LLHDL is lower level
<lekernel>
so you don't have to deal with the complex structures and idiosyncrasies of Verilog/VHDL to manipulate it
<lekernel>
larsc: also, going the "verilog model" way enables mixed simulations to be made
<lekernel>
ie simulate the LLHDL model of a part of the code along with the original Verilog of the rest
<lekernel>
this would also help in tracking down LLHDL toolchain bugs
<lekernel>
larsc: what do you think?
<lekernel>
ah, and LLHDL is _only_ for synchronous designs
<lekernel>
for asynchronous stuff, you have to manually instantiate the clock domain transfer elements at the boundaries
<lekernel>
a LLHDL simulator wouldn't handle that, but a Verilog one will...
<larsc>
hm
<lekernel>
at least, the event driven ones. there are also cycle-driven Verilog simulators, which have the same synchronicity requirement as LLHDL
<larsc>
what i would like to see is a simulator where you can write modules in non hdl languages, which allow you to model external behavior
<lekernel>
Verilator is probably what you're looking for :)
<lekernel>
compiles synchronous Verilog a library C++ classes, which you are free to link to anything you want
<lekernel>
it works great
<larsc>
not exactly what i want, but close
<lekernel>
a lot of great work has gone into verilator, so I'd rather recommend you find a way to link your other modules to C++ instead of starting from scratch...
<lekernel>
verilator-compiled modules are really fast. beats most verilog simulators, including the ones with big licenses
<lekernel>
and the design works on the real hardware
<rjeffries>
does MM1 have a microSD slot availble from exterior?
<lekernel>
no, it's only internal memory card
<lekernel>
you can think of it as a "hard disk"
<lekernel>
memory card hotplugging is too much software and mechanical trouble for what it brings
<rjeffries>
if ther e is something beyond MM1 (and I realize that is a big "if") would you consider adding a second 8:10 port to outside as an i/o? still have one internal as memory
<lekernel>
no idea :)
<rjeffries>
well as you know wpwrak's stuff are not memory cards. ;)
<rjeffries>
would be nice SWEET to leverage all his work
<lekernel>
unlike begin/end syntax, this one can make you waste days or debugging or even manufacture broken ASICs if you're not very careful
<wpwrak>
btw, do the numbers in increments/decrements always have to be sized ?
<lekernel>
in general it's good coding practice yes
<lekernel>
as I said, integer constants default to 32 bits
<wpwrak>
so the synthesizer is not (generally) expected to simplify this. pity. looks like a lot of redundancy. e.g., if you resize the register, then you also have to track down all of the operations on it. or would you get an error/warning if using a smaller/larger value ?
<lekernel>
actually, modern synthesizers do simplify this
<wpwrak>
(000388.html) hmm, subtle. there's a "not" missing in the explanation, no ? e.g., ''the scheduling of the "assign o=r_o" [...] may [not?] occur before you read o again''
<wpwrak>
(toporouter) mmh. an autorouter. isn't the common wisdom that they usually don't work ? :)
<Fallenou>
wo nice lekernel :)
<Fallenou>
I always found autorouters sucked
<wpwrak>
the context-sensitive menus in liquidpcb look interesting. that's a big nuisance in kicad. e.g., if you delete a track, and you click at/near a node, then you have to choose which of the segments you want to select. then, of course, "delete track" deletes all the segments of that track ...
<wpwrak>
(well, maybe it's better in the latest version. i'm a bit behind.)
<Fallenou>
yes that's a pain in the ass
<Fallenou>
but i havn't touch kicad for more than one year