<sb0>
whitequark: power-on-reset is useful in general for e.g. integrating verilog/vhdl cores that have a reset input
<sb0>
reset_less by default is fine, but changing it easily to a PoR signal is nice
<sb0>
though, I wonder of reliable reset_less actually is, in the general case. I don't see how the silicon could magically implement a reset sychronizer
<sb0>
*how
<sb0>
or, maybe there is something that turns on the BUFGs with some delay and without glitch?
<sb0>
most of my large designs have a reset signal because they use lm32 or or1k or because of some other reason
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
<rjo>
the cpcis cern project
mauz555 has joined #m-labs
<whitequark>
sb0: hmmm, you are right: GWE is asserted synchronously to the configuration clock (CCLK) and has a significant skew across the part. Therefore, sequential
<whitequark>
elements are not released synchronously to the user's system clock and timing violations can occur during startup. It is
<whitequark>
recommended to reset the design after startup and/or apply some other synchronization technique.
<sb0>
also, if you use a PLL to clock the design, you need to wait for it to lock
<sb0>
though xilinx has this STARTUP_WAIT feature that covers some cases...
<whitequark>
that's different: i'm only talking about the automatic insertion of clock domains at startup
<sb0>
if you use BUFGCE (and manage to control the CE pin correctly somehow) you may be able to make it work reliably
<whitequark>
yes, xilinx recommends that as one alternative.
<whitequark>
(couldn't they have just made GWE a proper global net?..)
<whitequark>
"Xilinx is highly confident that the vast majority of designs will not be affected." hm maybe they did
<sb0>
low skew is not enough, you also need a reset synchronizer
<sb0>
otherwise a clock edge at the wrong place during startup can put the design into a broken state
<whitequark>
oh, I see
<whitequark>
yes, they mention it but not very explicitly: Once the EOS signal asserts from the STARTUP primitive, the clock can be restarted synchronously to the user's systemclock.
<sb0>
low skew reduces the probability of this happening, but does not eliminate it
<whitequark>
yes, i understand now
<sb0>
isn't it simpler to just use BUFGCE? I suspect a flip-flop or two on CE could delay the clock startup sufficiently
<whitequark>
i'm reading its docs, actually
<whitequark>
so is BUFGCE's glitchless transition capability sufficient for synchronizing this?
<whitequark>
then it could be connected directly to STARTUP.EOS, right?
<sb0>
yes, BUFGCE (and BUFGMUX) are designed for glitch-free output no matter what the async control signals do
<whitequark>
yes. so this is a simple matter of connecting STARTUPE3.EOS to BUFGCE.
<whitequark>
mh, that's for series 7, i wonder about spartan 6
<sb0>
I would worry about ultrascale :)
<whitequark>
well, we don't have ultrascale in nmigen yet
<whitequark>
i'm trying to get the families that are nominally supported to work really well frist
<sb0>
why is S6 supported but not US?
<whitequark>
someone contributed S6 but no one contributed US?
<sb0>
S6 is getting long in the tooth, and despite its flaws, US is one of the most economical ways to have high-density logic
<sb0>
also it seems S6 can be often replaced with ECP5 performance- and density-wise, and then you don't have to bother with ISE
<whitequark>
i think S6 (and S3E) are only interesting for existing boards
<whitequark>
it's not really a problem to support them anyway as they all have BUFGCE.
<whitequark>
also, the only xilinx board i have on my desk has an S6...
<sb0>
well, that can be easily solved, there are plenty of 7-series/us/zynq boards here
<whitequark>
aren't they all very expensive?
<_whitenotifier-3>
[m-labs/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±10] https://git.io/fjHGp
<cr1901_modern>
whitequark: On Mercury, SRAM is multiplexed w/ the GPIO connector (which yes, has caused me a lot of problems in the past). Is it okay to use the "conn:no" syntax in SRAMResource?
<whitequark>
yes, it can be used anywhere an FPGA pin is expected
<whitequark>
and in fact you can even have hierarchical connectors
<whitequark>
as many levels as you want... try to not make a loop though :p
<cr1901_modern>
hierarchical connectors?
<cr1901_modern>
And cool, I'll refactor into SRAMResource
<whitequark>
like, imagine if you have a baseboard and it has pmods
<whitequark>
so a baseboard would add connectors that refer to connectors
<cr1901_modern>
I merged the SRAM and multiplex control signals into one resource, but... if any user has a mercury board, is using nmigen, and they want to use the SRAM, I think it's not much extra work to do `platform.request("ctl")` in addition to `platform.request("sram")`.
<cr1901_modern>
So I think I'll split them into two separate resources
<whitequark>
but then you can't use that with any design that expects the usual SRAMResource.
<whitequark>
nmigen.dev is basically types for resources
<whitequark>
(weak and structural types, so... almost not there, but still.)
* zignig
just managed to get working echo on v3.
<whitequark>
nice
<whitequark>
i'm still going through my backlog.
<zignig>
no rush. ;) , I'll have a longhand serial boot loader some time next week at this rate. (woohoo)
<whitequark>
i want to integrate a feature into boneless that lets you feed it instructions directly
<whitequark>
this way, you can boot it with SPRAM, without ever needing any BRAM
<whitequark>
also, it will make JTAG debugging possible.
<zignig>
I looked into adding an exposed reset today and wiring it into the UART so i can do a external hard reset and keep memory contents.
<cr1901_modern>
>but then you can't use that with any design that expects the usual SRAMResource.
<cr1901_modern>
Hmmm, you can't do this already anyway I don't think. Unless I'm misunderstanding something.
<zignig>
cr1901_modern: o/
<whitequark>
cr1901_modern: not with the layout you have. but if you rename the weird memwhatever pin to just oe, it should work
<cr1901_modern>
bussw_oe != oe
<whitequark>
oh?
<whitequark>
how does it work then
<cr1901_modern>
bussw_oe is used to disable the 5v tolerant level shifters, so your SRAM activity doesn't get propogated to the pins/connector
<cr1901_modern>
ce enables the SRAM, so if you're using the 5v tolerant I/O, the SRAM doesn't respond to activity on the 5v tolerant I/O pins accidentally
<cr1901_modern>
On Mercury, oe on the SRAM is tied to GND
<whitequark>
wtf??
<whitequark>
how do you write anything to it?
<cr1901_modern>
oe_n*, sorry
<cr1901_modern>
it's active low
<whitequark>
yes
<whitequark>
so its outputs are always active
<whitequark>
and you can't write anything to it
<whitequark>
this seems suboptimal
cr1901_modern1 has joined #m-labs
<cr1901_modern1>
whitequark: Took a look at the datasheet for the exact part number... /WE being low disables the tristate buffers on D0-D7
<cr1901_modern1>
I do not know if this is standard practice for SRAMs, but for this part it works
<cr1901_modern1>
CY7C1049DV33
cr1901_modern has quit [Ping timeout: 245 seconds]
<cr1901_modern1>
Geez, they went to A LOT of effort to make everything fit into 100 pins
<cr1901_modern1>
So yea the designers are taking advantage of part-specific SRAM behavior, because they wanted everything to fit into vq100
<cr1901_modern1>
wheee...
<cr1901_modern1>
So yea, Mercury is an S3 board. Few ppl using nmigen have it- I might be the only one. That said >>
<cr1901_modern1>
My opinion at this point is SRAM is so screwed on this board, it shouldn't even be called 'sram' to avoid trying to use it in designs that expect SRAMResource to obey a certain interface.
<whitequark>
cr1901_modern1: no, this is not part specific
<whitequark>
this appears to be normal SRAM behavior
<whitequark>
i think you can just make OE optional in SRAMResource
* cr1901_modern1
nods
<whitequark>
i've never actually used SRAM in a design
<cr1901_modern1>
Can't remember the last time I did, tbh
<whitequark>
i do have a board with SRAM here
<whitequark>
so i might like, plug boneless into it or something
<cr1901_modern1>
I could use an SRAM-tester IP to verify that I got the SRAM interface and timing correct for a given board/clock/etc. Boneless would make that easy to design (the SRAM under test would be on the I/O bus)
<cr1901_modern1>
>i think you can just make OE optional in SRAMResource
<cr1901_modern1>
Do you want me to add this and make a PR?
<whitequark>
yes
<cr1901_modern1>
Will do... gimme a few mins (eating breakfast, whoops)
<whitequark>
oh for fuck's sake, ISE crashes trying to find my MAC... because I have no eth0 probably
<whitequark>
does ISE's settings script require bash?
<whitequark>
yes it does ;_;
cr1901_modern1 has quit [Quit: Leaving.]
nurelin has joined #m-labs
cr1901_modern has joined #m-labs
nurelin has quit [Client Quit]
<_whitenotifier-3>
[nmigen-boards] cr1901 opened pull request #26: [breaking-change] Make oe in SRAMResource optional. - https://git.io/fjHWn
<_whitenotifier-3>
[nmigen-boards] whitequark commented on pull request #26: [breaking-change] Make oe in SRAMResource optional. - https://git.io/fjHW0
nurelin has joined #m-labs
<_whitenotifier-3>
[nmigen-boards] whitequark commented on pull request #26: [breaking-change] Make oe in SRAMResource optional. - https://git.io/fjHWu
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fjHWz
<_whitenotifier-3>
[m-labs/nmigen] whitequark 5eb4e2e - build.plat: allow selecting a specific UNIX shell interpreter.
<_whitenotifier-3>
[m-labs/nmigen] whitequark 6b025df - vendor.xilinx_spartan_3_6: force use of bash on UNIX.
<whitequark>
you can type *args and you get positional arguments collected into a tuple. or, you can type * and there won't be any permitted positional arguments after that
<whitequark>
it's very useful for boolean flags
<whitequark>
so you don't get foo.do_thing(True, True, False)