<cr1901_modern>
ysionneau: Figured out how to add spiflash to my SoC design. Incredibly, having the onboard ROM actually takes up less space than an SPI master that talks to Flash memory.
<cr1901_modern>
Or more accurately, I don't run out of slices (1 slice == 2 flip-flops and 2 4-input LUTs) on my FPGA if I go the onboard ROM route
<cr1901_modern>
Incidentally, I lost the changes I made to lm32_config.v earlier today during a stash, so I'll just play around with things later...
mumptai has joined #m-labs
FabM has quit [Remote host closed the connection]
FabM has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
fengling has quit [Ping timeout: 256 seconds]
<GitHub106>
[migen] enjoy-digital pushed 2 new commits to master: http://git.io/vUoyS
<sb0>
the kernel releases attempt to find brcmfmac43241b4-sdio (not b5) - so you may need to fool them
<sb0>
the tablet does need b5 firmware
<sturmflut>
Argh, that might have been the probem. Thanks a lot.
<sturmflut>
And you took the configuration from the EFI variables?
<sb0>
the weird txt file? yes
<sb0>
with efivarsfs
<sturmflut>
yep
fengling has joined #m-labs
<sb0>
i wonder why they need this annoying text file at all, since the card has nv storage for the MAC address
<sb0>
wouldn't have been much more expensive to add a few hundred bytes of eeprom to store that file's info and avoid that efi mess
<sb0>
maybe those few hundred bytes are actually there, sitting unused :-)
<sb0>
I wouldn't be surprised given the quality engineering that went into this tablet
<sturmflut>
sb0: I think I read somewhere that one of the options for this chipset is to even build it without the NVRAM. These Broadcom chips can be used in so many different setups and devices, probably the Linux driver developer couldn't be sure what the manufacturers will do in the end.
<sturmflut>
sb0: But they could try to walk all known places. The driver could e.g. extract the EFI variable by itself, and if that doesn't work look for the text file etc.
<sb0>
yeah, the windows driver does that...
<sturmflut>
If I remember correctly one of the Broadcom developers on the linux-wireless list talked about doing this a while ago
<sturmflut>
But they seem to have bigger problems
fengling has quit [Ping timeout: 276 seconds]
fengling has joined #m-labs
<whitequark>
gross
<ysionneau>
pipistrello board is hot as hell
<ysionneau>
(I mean it's heating a lot :p)
cr1901_modern has joined #m-labs
<ysionneau>
cr1901_modern: it's not incredible in fact, onchip ROM uses blockram hard IPs which cannot be used for logic, so wether you use them or not it does not make the FPGA more or less full
<ysionneau>
cr1901_modern: so not using those blocks does not free much logic, but adding the flash controller adds up logic which can possibly make the design not fit if the FPGA was already almost full
<cr1901_modern>
I see. Well, I'll just play around with it until things fit. I do know that simple.py in it's unaltered form used more than 10*s the resources my FPGA provides (and this was b/c of the default onboard RAM size)
<ysionneau>
ram size should not change the resource occupation :o since ram uses blockram
<ysionneau>
if you specify too high ram size though, it will start using logic elements to provide ram which will explode the resource occupation
<ysionneau>
so maybe the defautl value for ram size is already too high for your FPGA
<cr1901_modern>
^That's most likely what happened :P
<ysionneau>
you have the 200k one?
<cr1901_modern>
Indeed
<ysionneau>
datasheet says it has 288 Kbits of blockram
<cr1901_modern>
and 28kb of distributed IIRC
<ysionneau>
yes
<cr1901_modern>
From what I understand, the latter is easier to use
<cr1901_modern>
i.e. the PAR can more easily allocate distributed
<ysionneau>
well, the blockram, being a hard ip has fixed location, if I'm correct distributed can be placed more freely
<ysionneau>
but distributed ram quickly eats up your fpga resources
<ysionneau>
but if you need async ram, you must use distributed since blockram is only synchronous (afaik)
<cr1901_modern>
Might have to disable both of the caches
<cr1901_modern>
or keep them disabled or make them small (not a huge deal)
<ysionneau>
try to make them smaller + reduce sram size, maybe it will make the blockram usage fall under the 288 Kbits limit
<ysionneau>
I guess you removed ethphy and ethmac from simple.py ,
<ysionneau>
?
<cr1901_modern>
Yes indeed XD
<ysionneau>
or maybe you just use BaseSoC
<cr1901_modern>
Oh, I already spun off simple.py into a new file just for mercury
<ysionneau>
ok
<ysionneau>
uart has rx and tx fifo also
<ysionneau>
maybe you can reduce the fifo size
<ysionneau>
(or disable them? dunno)
<cr1901_modern>
I certainly have options to make it fit. Right now, the FPGA has 86% slice usage
<ysionneau>
k
<cr1901_modern>
that's with simple.py with a bit of onboard ROM. The actual number of LUTs and flipflops used is less than 86% of course
<cr1901_modern>
I'm optimizing for area
<ysionneau>
about the SRAM, I'm looking at the schematic right now, it seems to be directly connected to FPGA :o
<cr1901_modern>
yes, it is. Depending on the logic, it's either gonna be zero or 1-wait state SRAM
<cr1901_modern>
so cache might not even be needed- the main reason I wanted it is something to experiment with b/c I'm not exactly great with cache as a concept.
<ysionneau>
so implementing the sram controller will be easy
<ysionneau>
I thought you said some i/o were shared with some other part of the board
<cr1901_modern>
it is... th 5V tolerant I/O is shared with the SRAM pins. One switches between them using an FPGA pin that disables/enables the logic shifters
<cr1901_modern>
It's still not tough to do- it should be as simple as an address decoder that decodes either the 5V I/O region or the main memory region and then enables the BUSSW_OEN and MEN_CEN control signals accordingly
<ysionneau>
ok, I don't understand this by reading the schematic :(
<ysionneau>
I just see MEM_CEN connected from FPGA to SRAM
<ysionneau>
acting like some kind of chip select
<ysionneau>
ah ok I see that the A[] D[] and WEn pins are shared with the I/O buffers
<cr1901_modern>
MEM_CEN goes to the SRAM's chip select
<cr1901_modern>
yes, you got it
<cr1901_modern>
Since this CPU's not going to access two memory regions simultaneously, it should be perfectly safe for me to write a small custom controller
<cr1901_modern>
that checks the address that is to be accessed, and changes the control logic accordingly
<ysionneau>
yep it seems to work
<cr1901_modern>
Thankfully, lm32 has cacheable regions that I can change, so the 5V tolerant I/O space doesn't need to be checked against the cache's address using custom logic XD
sturmflut is now known as sturmflut2
<cr1901_modern>
I'm still waiting to hear back wrt how to communicate over serial using the particular dev board. In the meantime, I just sacrficed two GPIO pins for a 3.3V serial port lol
<ysionneau>
=)
SturmFlut has joined #m-labs
SturmFlut has quit [Ping timeout: 272 seconds]
<GitHub88>
[artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/vUiNr
<GitHub88>
artiq/master cbb5027 Sebastien Bourdeauducq: gateware/ad9858: use WaitTimer from Migen
<GitHub88>
artiq/master e557d7e Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/artiq
antgreen has joined #m-labs
larsc has quit [Remote host closed the connection]
<rjo>
ysionneau: my pipistrello does not get above ~40C with artiq running.
ohama has quit [Disconnected by services]
felix__ has joined #m-labs
ohama has joined #m-labs
felix_ has quit [Ping timeout: 250 seconds]
felix__ is now known as felix_
antgreen has quit [Ping timeout: 272 seconds]
<cr1901_modern>
sb0: Where does MiSoC put the linker script for the generated SoC target?