<cr1901_modern>
_florent_: My bad with the source=True default XD. I actually misunderstood what the source option was for. I thought it just prevented deleting the project files.
<cr1901_modern>
(But you meant source in the bash sense, not the "source code" sense)
<_florent_>
hi cr1901_modern
<cr1901_modern>
hai. Saw your additional changes after I posted on the mailing list, so thanks.
<_florent_>
np, that's just that since the tools are generally not in C:\Xilinx, I find easier to define it in the PATH.
<cr1901_modern>
They aren't? Tbh, I don't remember setting the path.
<cr1901_modern>
when installing the tools*
<_florent_>
No they are not, but I prefer doing it than having to set ise_path in the misoc command line everytime I build something :)
<GitHub75>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/vLVnT
<GitHub75>
migen/master 71627cf Florent Kermarrec: bus/wishbone: remove size CSR from Cache (L2 size will be reported to the software as a constant)
<GitHub122>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vLVnn
<GitHub122>
misoc/master f44956b Florent Kermarrec: soc/sdram: add L2_SIZE constant and avoid declaring an empty flush_l2_cache function when L2_SIZE is not defined
<cr1901_modern>
Oh... whoops. I thought I just accepted the default paths when installing ISE. So the future users of Migen on Windows- all 3 of them- might still have to do some manual set up.
<_florent_>
that's something generally considered as part of the installation on windows :)
<cr1901_modern>
Well, I suppose we can assume that if one is using Migen in the first place, they are comfortable with doing manual set up/playing with the command prompt.>>
<cr1901_modern>
I just wanted to decouple migen from MSYS personally because my editor provides a built-in cmd.exe (to avoid window switching), but couldn't actually run MSYS/bash inside that cmd.exe instance.
<_florent_>
yes, thanks for that!
<cr1901_modern>
Np :). (Aside: I use jedit. Surprisingly competent editor with a built-in console that crashes 99% less than Notepad++)
<GitHub179>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vLVWk
<cr1901_modern>
_florent_: You added the wishbone cache module, correct?
<_florent_>
yes
<_florent_>
(it's mostly identical to old WB2LASMI module)
<cr1901_modern>
I'm a little bit confused about the FSM, particularly the IDLE state. >>
<cr1901_modern>
Since master.cyc and master.stb are synchronous, if we are in idle state, they would've been asserted at the prevoous clock edge, correct?
<cr1901_modern>
When leaving the IDLE state, shouldn't we have already prepared the data to be sent or insert a wait state?
<cr1901_modern>
but in the case of the cache FSM, neither is done.
<_florent_>
hmmm, not sure I understand
<cr1901_modern>
I just cannot grok the wishbone spec. It should be easy, but... bleh
<_florent_>
master is the bus initiating the access
<_florent_>
(yes wishbone spec is not a model...)
<cr1901_modern>
what do you mean by that? :P
<cr1901_modern>
Right... and when does the slave see that master.cyc and master.stb are asserted? BEFORE the clock edge or after the clock edge?
<cr1901_modern>
The FSM doesn't make sense to me if it's the latter case, based on the timing diagrams I'm reading
<_florent_>
(I meaning that in the wishbone spec 90% of the information is not useful, which make it really difficult to read...)
<_florent_>
in Migen, fsm are asynchronous
<cr1901_modern>
Well, at least someone else feels the same way. That makes me feel a bit better.
<cr1901_modern>
ysionneau: Are you around? I think I'm actually just about ready to send a patch for preliminary Mercury support (only a few weeks late) lol
<ysionneau>
yes I'm here :)
<cr1901_modern>
https://gist.github.com/cr1901/a3369379a1dda5d42ba3 Thanks to looking at MiSoC, I've learned that it's possible to have multiple peripherals use the same pins, and mibuild will keep track of what pins are left
<cr1901_modern>
This is preliminary, but based on what sb0 and I discussed (the dual SRAM/GPIO should be it's own special peripheral), I think what I have should work.
<cr1901_modern>
Just one question: What is the _connectors field meant for XD?
<ysionneau>
ah yes, you can have multiple piece of code doing the plat.request() , as long as just one runs on a particular design
<ysionneau>
_connectors is an abstraction that allows to group together I/O pins
<ysionneau>
usually the pin headers on the boards
<ysionneau>
but it can also act for other connectors like hispeed connectors
<ysionneau>
in KC705 it's used for the FMC (HPC+LPC) connectors
<cr1901_modern>
Okay, then I probably did it correctly. The one thing that irritates me about this board is that SRAM and 5V GPIO are shared, and I've actually devised a way to use them both simultaneously.
<ysionneau>
you can either just index the pins in the connector
<ysionneau>
like it's done in pipistrello.py platform file
<ysionneau>
or you can name each pin, like in kc705.py using a dictionary
<cr1901_modern>
I went the former route for Mercury.
<ysionneau>
good that you have completed the platform file for Mercury :)
<cr1901_modern>
Well, to the extent that I believe it's correct. I want to actually get it into the tree if sb0 will let me, b/c the board designers expressed interest in helping.
<ysionneau>
the best to make sure it's correct is to also have a small (even very limited) misoc target using it
<ysionneau>
but you can also just test each platform pin with simple cpu-less designs I guess
<cr1901_modern>
Simple LED/push button designs do work.
<cr1901_modern>
I've been trying to create an SRAM controller, but have been having a lot of trouble with it- maybe I'm in a fog, can't really grok wishbone.
<cr1901_modern>
It's the stupid dual GPIO/SRAM design that's messing with me.
<ysionneau>
try first a static design only allowing SRAM access with no GPIO maybe?
<ysionneau>
then when this works, try adding support for the gpio
<cr1901_modern>
That's probably for the best. I've been carefully trying to divide the GPIO and SRAM interface into decoupled modules, that both communicate with a third module that actually connects to the inout pins
* cr1901_modern
grumbles at the FPGA size
<ysionneau>
hehe
<cr1901_modern>
This is why I want to add features in steps. I will also have to create a new configuration for smaller lm32 boards
<cr1901_modern>
lm32_config.v in it's normal version is too big for the FPGA. I can fit- unpipeline barrel shift/multiplier/divider, d/icache, timer, identifier, uart, and SPIflash.
<cr1901_modern>
Perfect for a small board, except for that part where there's basically no RAM- on chip or off XD.
<cr1901_modern>
So my goal is to add an SRAM controller- which requires a down converter and THEN the controller itself. That's going to exceed the FPGA space. So I need to get rid of something.
<cr1901_modern>
Can't get rid of either cache (already at smallest setting)- performance will be destroyed on any memory access. So I most likely will get rid of division/have gcc emulate it through multiplies
<cr1901_modern>
(Sorry for using the chat as a soapbox, but this is what I've been batting around while trying to add support)
<ysionneau>
you can disable the caches though, it won't reduce the size by a lot, but can still free up some resources (FSM etc)
<cr1901_modern>
Yes, and it does free resources. The problem with that is every memory access ends up stalling the pipeline then.
<cr1901_modern>
So I figure disabling division would have less of a performance impact in practice.
<ysionneau>
sure
<ysionneau>
I was just suggesting that if you need to squeeze more resources
<cr1901_modern>
Understood.
<cr1901_modern>
Or maybe I can disable one cache (dcache) as a compromise. I still haven't actually figured out how to use the special resources of my FPGA (synchronous block RAM, etc)
<ysionneau>
Xst should automatically infer blockram for the caches
<cr1901_modern>
Oh, then my FPGA's just too small and I'm trying to bravely fit more stuff onto the device than intended XD
<ysionneau>
yep, the cache in itself should not take any resources except blockram
<ysionneau>
only the muxes+FSM+logic controlling the blockram should take resources
<ysionneau>
you can easily check that in the synthesis report
<ysionneau>
or just the console output when synthesizing
<ysionneau>
it should print the number of blockram used, and the infered blockrams
<cr1901_modern>
Hmmm, let's see...
fengling has quit [Quit: WeeChat 1.1.1]
<cr1901_modern>
Does block ram = RAMB16BWEs?
<ysionneau>
yes
<cr1901_modern>
50% used
<ysionneau>
if you have a look at when Xst analyzes lm32_dcache.v you should see it infer a blockram
<ysionneau>
but it seems you are using the blockrams so it seems OK
<cr1901_modern>
Yes, you're indeed correct
<cr1901_modern>
Let's see what happens when I increase the cache size then...
<cr1901_modern>
Incidentally, I have `define CFG_EBR_POSEDGE_REGISTER_FILE uncommented.
<cr1901_modern>
Yea, this is hilarious... Number of RAMB16BWEs 6 out of 16 37% when `define CFG_EBR_POSEDGE_REGISTER_FILE is commented out. vs. 50% when uncommented
<cr1901_modern>
The synthesizer isn't smart enough to place the reg file in block RAM...
<cr1901_modern>
ysionneau: What's the syntax for requesting a connector pin?
<cr1901_modern>
plat.request("INPIN") #This doesn't work
<ysionneau>
you can have a look at how it's done in artiq
<ysionneau>
you need to call platform.add_extension()
<ysionneau>
then you will be able to do platform.request("name_in_the_adapter")
<cr1901_modern>
In the context of the mibuild file, _connectors is passed to the GenericPlatform constructor, so it feels as if the connectors should be available
* cr1901_modern
tries harder to parse the code
<ysionneau>
you have the connectors pins which have connector pin names if you are lucky, or just numbers if you are not
<ysionneau>
then you have what each pin really represent, for instance the pin name on the board schematic which you will plug to the connector
<ysionneau>
in the platform file you can only represent the connector, because ... that's what is on the board
<ysionneau>
then in your design file, you can describe the pin names of the daughter board you will plug on this connector
<ysionneau>
maybe that's more clear?
<cr1901_modern>
Oh alright.
<cr1901_modern>
I get it now. In effect, _connectors represents the extra pins available for further customization using mibuild after all peripherals have been accounted for
<cr1901_modern>
If there are no extra pins specified in _connectors, you can't add peripherals/"custom pin designations"
<ysionneau>
yes _connectors mean you will be able to plug something that could be different from design to design
<ysionneau>
so it cannot be described in the platform file
<ysionneau>
it must be described in the design
<cr1901_modern>
(7:12:52 AM) ysionneau: you have the connectors pins which have connector pin names if you are lucky, or just numbers if you are not <-- just numbers?
<ysionneau>
if the connector is named A
<ysionneau>
pins could be A[0] A[1] etc
<ysionneau>
most connectors just number the pins
<ysionneau>
but sometimes they give meaningful names
<ysionneau>
like FMC standard
<ysionneau>
or jtag
<cr1901_modern>
In kc705, _connectors is a list of tuples consisting of a string and a dictionary. In pipistrello and others, _connectors is a list of tuples consisting of two strings.
<cr1901_modern>
I guess ConnectorManager detects which version you specified and creates the "database" accordingly
<ysionneau>
13:22 < cr1901_modern> I guess ConnectorManager detects which version you specified < yes
<ysionneau>
both can work
<ysionneau>
the first you mentioned allows you to give names to pins
<ysionneau>
the second just numbers them, for instance in papilio you just have the connector name 'A' or 'C' and then a pin number
<ysionneau>
for instance 'C:1'
<cr1901_modern>
The number scheme makes more sense for Mercury because the pins are labelled by numbers
<ysionneau>
there you go then :)
<cr1901_modern>
At this point, I think officially, the mibuild file for Mercury is now done (at least the first version).
<ysionneau>
good!
<cr1901_modern>
Only took me two months on and off to write those 100 lines lmao
<cr1901_modern>
I now need to finish writing a command-line programmer for Mercury (or alternatively, add the FT245 chip to xc3sprog). Let's see if I understand this properly:
<cr1901_modern>
1. load-bitstream() just loads the bitstream to flash memory.
<cr1901_modern>
2. flash() assumes that the FPGA already has been programmed with a valid configuration, and attempts to load a file to the FPGA which in turn fills the rest of flash memory
<cr1901_modern>
Yea, I'm gonna have to buy a real JTAG cable for this methinks.
antgreen has joined #m-labs
sb0 has joined #m-labs
<ysionneau>
sb0: Hi, I will be unavailable on saturday, I will be at my sister's wedding
<sb0>
ok
<sb0>
np
<ysionneau>
it seems indeed one can grep for serial number using hwgrep://
<ysionneau>
hwgrep://SNR=<the_serial_number>
<sb0>
ok, please add to doc and -h
<ysionneau>
ok
<ysionneau>
sb0: about the segfault in hidapi, having distributions like ubuntu (or worse, Debian) ship updates can take a long time ... :/
<ysionneau>
but yes it's the "correct way"
<sb0>
i know, but the segfault should only happen when the device permissions are incorrect, right?
<sb0>
so it's a rather minor issue
<ysionneau>
yes
<GitHub67>
[artiq] fallen pushed 1 new commit to master: http://git.io/vLrEb
<GitHub67>
artiq/master 4cdf1c4 Yann Sionneau: manual: serial number explanations + udev rule for LDA
<ysionneau>
plus, I added some info about how to add udev rule
<ysionneau>
to avoid segfault, even when non root
<ysionneau>
sb0: for Tcube controller, do I replace the -d/--device with a -s/--serialnumber and only allow to provide serial number (that I push into hwgrep) and do not allow anymore to provide a /dev/ttyUSB** ?
<sb0>
ysionneau, just give access to the serial_for_url argument and explain and recommend using hwgrep in the doc
<ysionneau>
all right
<GitHub30>
[artiq] fallen pushed 2 new commits to master: http://git.io/vLr68
<ysionneau>
sb0 : I will add an example for the VID/PID/SN on monday, now I don't have the usa plug converter to check the PID/SN on the actual device, my gf just took it for a trip. I will buy one on monday and add the missing example
antgreen has quit [Ping timeout: 250 seconds]
ohama has quit [Remote host closed the connection]
ohama has joined #m-labs
mumptai has joined #m-labs
<GitHub57>
[artiq] fallen pushed 2 new commits to master: http://git.io/vL6IZ
<GitHub57>
artiq/master d646984 Yann Sionneau: manual: link cleanup
<GitHub57>
artiq/master 188a9fb Yann Sionneau: manual: add hwgrep example for TDC
<ysionneau>
the Thorlabs TDC doesn't even use its own vendor ID, they use the FTDI one