Back
[11:48:08] <jepler> > German chipmaker Dialog Semiconductor (DLGS.DE) has agreed to buy U.S. rival Atmel (ATML.O) for about $4.6 billion, amid a wave of dealmaking in the sector as firms seek alternatives to saturated mobile phone markets.
[11:53:38] <jepler> RISC-V implementation in verilog, Small (~1000 LUTs in a 7-Series Xilinx FPGA), High fMAX (~250 MHz on 7-Series Xilinx FPGAs), ISC license
https://github.com/cliffordwolf/picorv32
[11:54:52] <jepler> slow, though, 3-15 cycles per instruction (3-6 excluding shift ops), 40 and 72-cycle multiplies
[11:55:01] <pcw_home> Yuck
[11:56:11] <pcw_home> how can they call it risk if its not 1 clock/inst
[11:56:22] <pcw_home> RISC
[11:57:20] <pcw_home> B32 will run at 250 MHz in Artix, 1 clock/inst
[11:58:20] <jepler> none of your cores can be targeted with gcc :-P
[11:58:58] <jepler> I guess RISC-V is an instruction set but doesn't mandate pipelined implementation.
http://riscv.org/
[11:59:02] <pcw_home> Yeah but 3/5 clocks/inst is dreadful
[11:59:40] <jepler> yeah I got less excited when I got that far down the page
[12:01:01] <pcw_home> if it takes 40 to 72 inst for multiply, it must use shift/add which is funny since something
[12:01:02] <pcw_home> like 50 parallel multipliers are available on the smallest series 7 FPGA
[12:02:36] <pcw_home> should take no more than 3 or 4 250 MHz clocks for a cascaded parallel 32 --> 64 mult
[12:03:47] <jepler> yes
[12:03:54] <pcw_home> But if you dont need speed, 1000 LUTs is quite small
[12:05:08] <jepler> 1 spartan3 slice = 4 LUTs?
[12:05:31] <jepler> (the comment in b32.vhd says it's ~490 slices)
[12:06:24] <pcw_home> it depends on family newer chips have more LUTs/slice
[12:07:54] <pcw_home> SP3 is 2 LUTs/slice
[12:09:47] <pcw_home> SP6 is 4 LUTs/slice
[12:10:33] <pcw_home> (SP6 uses 6LUTS instead of 4LUTS thats SP2/3 use)
[12:11:45] <pcw_home> series 7 is also 4 LUTS/slice
[12:11:50] <jepler> huh riscv variants include a 128-bit address space. I guess two programs need never ever ever allocate the same address for code or data.
[12:13:19] <pcw_home> Seems a bit excessive for an embedded processor
[12:14:00] <jepler> It is not clear when a flat address space larger than 64 bits will It is not clear when a flat address space larger than 64 bits will It is not clear when a flat address space larger than 64 bits will It is not clear when a flat address space larger than 64 bits will It is not clear when a flat address space larger than 64 bits will >
[12:14:06] <jepler> It is not clear when a flat address space larger than 64 bits will be required. At the time of writing, the fastest supercomputer in the world as measured by the Top500 benchmark had over 1 PB of DRAM, and would require over 50 bits of address space if all the DRAM resided in a single address space.
[12:14:11] <jepler> > Some warehouse-scale computers already contain even larger quantities of DRAM, and new dense solid-state non-volatile memories and fast interconnect technologies might drive a demand for even larger memory spaces.
[12:14:15] <jepler> > Exascale systems research is targeting 100 PB memory systems, which occupy 57 bits of address space. At historic rates of growth, it is possible that greater than 64 bits of address space might be required before 2030.
[12:14:31] <jepler> I guess if you think something will be needed by 2030, why not start building it now.
[12:14:45] <pcw_home> hmm
[12:19:12] <pcw_home> did you see that email from Karlsson & Wang about hm2_eth not starting properly some times?
[12:19:26] <jepler> no, I'll look.
[12:19:42] <pcw_home> (I think this is with his remote hardware)
[12:21:07] <pcw_home> There may be a possible buffer overrun issue during startup if a large number of
[12:21:09] <pcw_home> initialization writes are done without some reads
[12:22:12] <jepler> hm, I know that prior to 2.7.0 I did fix some startup problems and my own testing ran 1000s of startups without error. before that, it was pretty flaky and we both saw startup failures at a frequency over 1-in-10
[12:22:29] <pcw_home> ( probably hard do do with our hardware because its pretty fast and has a 12K byte RX buffer in the Ethernet chip )
[12:23:00] <pcw_home> Yeah I should ask if he is running 2.7
[12:23:09] <pcw_home> 2.7.0
[12:24:03] <jepler> yes I think the driver probably does not have adequate safeguards against sending oversized packets, or sending requests that would lead to oversized packets
[12:26:46] <jepler> what is his "remote hardware"?
[12:40:47] <pcw_home> not exactly sure but I remember he implemented the remote part of hm2-eth on a micro
[12:48:12] <jepler> oh so he's not using mesa hardware on the other end
[12:48:18] <jepler> I see
[12:52:15] <pcw_home> yeah maybe pre 2.7.0 or maybe smaller buffer not sure. I answered with my guesses
[12:53:23] <pcw_home> I think hes using a stock micro IP stack (LWIP?) so its likely a bit slow
[13:07:25] <jepler> I sure didn't pay as much attention to outgoing packets during the initialization phase
[13:07:46] <jepler> it works, why mess with it, etc
[13:09:04] <pcw_home> Yeah, so its possible there's a buffer overrun on some hardware
[13:12:48] <pcw_home> Our hardware is really simple, single-threaded so synchronous, so embedding a
[13:12:50] <pcw_home> read (and waiting for the rx data) at the end of a large write packet will guarantee sync
[13:12:51] <pcw_home> Not sure if the same applies to his hardware
[13:13:48] <jepler> UDP doesn't guarantee order
[13:14:06] <jepler> but I'm not sure how that'd be relevant here
[14:10:07] <jepler> in normal operation from the periodic task, it would not be beneficial to require a read just to complete a write
[14:10:40] <jepler> but in startup it would keep the initial setup writes from overrunning some too-small buffer
[14:15:35] <pcw_home> yeah
[14:22:21] <pcw_home> ultimately for periodic code it would be good if writes wrote a serial number that was checked
[14:22:22] <pcw_home> on the next read and any detected write failures set a HAL flag
[14:22:24] <pcw_home> Just as read should timeout in a reasonable % of the servo period and also set a HAL flag "stale read data"
[14:22:25] <pcw_home>
[14:25:57] <pcw_home> The stale-read flag could tell PID to "vamp until ready" for example
[14:25:58] <pcw_home> so a dropped packet has minimal effect, basically just lowers the control bandwidth for one cycle
[15:38:09] <jepler> on my test card, 203 packets are sent or received during startup. At one point, 22 consecutive write packets are sent within about 100us.
[15:38:38] <jepler> that's for a 7i80 with 1 encoder, 1 pwmgen, 1 stepgen
[15:40:00] <pcw_home> That may well overwhelm a slower micro
[15:40:45] <pcw_home> at least if it does not have enough packet buffer space
[15:53:04] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-WIP-hm2_eth-batch-writes-from-hm2_force_write.patch
[15:53:21] <jepler> this batches up that block of 22 consecutive writes into one 200-byte packet + 1 32-byte packet. I didn't trace what that last 32-byte packet was yet.
[15:53:24] <jepler> lightly tested.
[15:53:33] <jepler> have to go out the door or I'd post it on that thread
[17:40:06] <skunkworks> I think you guys nailed it'
[18:20:13] <PCW> what? our foot to the floor?
[18:25:06] <skunkworks> pcw, You have isolated pwm to analog
[18:46:28] <mozmck> Is that something new?
[19:24:34] <PCW> single ended, yes
[19:46:33] <Tom_itx> like on the 7i47s?
[20:21:20] <PCW> yes
[20:21:51] <PCW> I have a +-10V card but i have not had time to build the proto
[21:25:25] <skunkworks> I think I should just get a
[21:33:33] <jepler> in other words you'd like to buy a vowel?